Comments (4)
Thanks to @njsmith for pointing out the traceback serializers in jinga2
and also @dhirschfeld for pointing out tblib
which seems to be derived from it.
from tractor.
error propagation that somehow includes explicit mention of host boundaries in a readable way
I think this should mostly be included in a mailbox / address in every message (the actor model way). Right now tractor
is kind of doing this by having each portal aware of the far end address on either side. I'm trying to think of whether it matters if an actor is local to the host or remote - maybe just for certain network-comms related error handling? A lot of this will be delegated to lower layers in tractor
(depending on IPC transport - TCP versus NNG etc.) so I guess relying on specific error types that might change across versions might pose a problem? I feel like a decently designed exception inheritance tree should mostly cover this?
If there were some way to give a good representation of which version of the code it found on the other side as well, that seems really excellent.
In my mind the the primary code that cares about remote errors is an actor's supervisor, and I wonder, should a super care about what version of the code is being run? Is this maybe the concern of something else? For example, if the application required that info couldn't the parent just immediately ask for a version from its child just after spawning? When will it be useful to a super in the general case to know about its child's code version? Maybe in a system where there is hot code swapping like in erlang
? I'm still not even sure if such a feature should be built into the core of tractor
- might be better oriented as a small "native app" on top?
I think the main question is how much does a remote super need to know about a child's error types / internal code. To me, too much coupling here would mean the super is more part of the app then part of distributed computing system - which maybe is fine in some cases but then won't the super need to have special consideration for details of the child anyway? At face value it would seem to me a super needs to know as much about a child's remote errors as a try
/except
block needs to know about code it calls (that may change in future revisions). The except:
blocks here can be many, specific, and as nested as desired?
If a super is supposed to fulfill its conventional role then I think some set of error "classes" might be necessary to help (custom) supervisor authors determine what types of failure recovery (or cancellation) logic is available. Having a set of contracts for what errors should be raised in which situation is something that can be iterated over time if designed right - but still there will be a foreseeable super handlers-to-error types compatibility problem over multiple versions running in the same cluster(s).
Anyway, too many new questions
The short assertion is that we already do pack task info in the exception msg and announce / pack the actor uid in the RemoteActorError
on the receiving side.
I don't at the moment see any problem with requiring all such remote errors to include the address/actor uid/ task uid info in every error. It's probably just going to make logging system integration that much easier and useful. I also don't see a problem with reconstructing remote errors into local objects other then performance.
from tractor.
More hints from celery
on exception pickling?
from tractor.
I think that we want to have error propagation that somehow includes explicit mention of host boundaries in a readable way. That's probably the relatively easy part of the issue, but I don't want it to be overlooked. The traceback should show when the host/process changes, which means that the code itself may be different. If there were some way to give a good representation of which version of the code it found on the other side as well, that seems really excellent.
Of course, if everything really is on the same version of the same code, then it'll be redundant. And we could, when things are happy, potentially unseralize the exceptions and raise them as more than just a wrapper exception with the traceback from the other server, which would be cool. Not something that we can rely on in all cases though, so we have to have a good fallback when things don't match and the exception and traceback don't propagate well.
This is all really interesting, and I don't know what I'm talking about, but it looks very neat.
from tractor.
Related Issues (20)
- Nursery does not re-raise error from `.run_in_actor()` remote task HOT 22
- Deprecate `ActorNursery.run_in_actor()` and offer as part of a wrapper cluster API HOT 1
- PyPI packaging broken for version 0.1.0a4; missing README.rst HOT 2
- Toying with a message type for "object references" HOT 1
- Add a basic *registry* actor example
- tHe GoD uNpRoToCoL HOT 1
- Caps based sec, as much as we can with Python
- We might not need `ActorNursery._join_procs: trio.Event` in the long run
- Use of `pydantic` and `click` in sub-actor causes SIGINT ignoring, hangs...
- Macos error while trying to initialize HOT 2
- Need to handle a `KeyError` in `_debug._hijack_stdin_for_child` HOT 2
- Drop `msgpack` dependency, go full `msgspec`
- Handling >= 1 depth (nested) actor trees in the debugger
- `pdbpp` borks our `0.1.0a5` on `pypi` 😂
- Recursion error on `BroadcastReceiver.receive()`?
- `trio.Process` deprecations
- `trio.MultiError` is deprecated -> move to `exceptiongroup.ExceptionGroup` HOT 1
- Share memory (array) sub-system API and optional tight integration with `numpy`
- OS X: shared memory file name length limitation causing error
- `OSError: [Errno 9] Bad file descriptor` in cluster test
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from tractor.