RFC - add basic exception details to terminated message

[sudsy]

I had a look to see if this has been discussed before and can't seem to find it.

I have found that when working with remote actors, I typically have to watch the remote actor for unexpected terminations and also set up a parallel mechanism for reporting error types / messages back from the remote actor to the supervising actor to decide whether to restart a new remote or fail and report back to the user.

I can see that this parallel mechanism would be avoided if we attached some details of the error to the terminated message such as type, message and stack trace.

Any comments / concerns about doing this?

[rogeralsing]

This one is somewhat tricky, firstly, we need to propagate the exception details over the wire, secondly, it needs to make sense between runtimes. e.g. Go talking to .NET

If it is just plaintext for logging, then absolutely, that can be implemented.
Or, if it's about knowing why someone terminated. e.g. Stopped/Exception/Poisoned that could also be implemented.

Thoughts?

[rogeralsing]

We already have the AddressTerminated Bool on Terminated message.
Maybe we could replace this with a Reason prop with different stathuses.

ActorStopped
ActorPoisoned
ActorStoppedBySupervisor
AddressTerminated

Something like that?

[sudsy]

I think for my purposes the combination of the statuses you have listed above and a simple string that contains the exception message would work. Would that work across the different runtimes?

That way I could propagate an exception message all the way back to the caller if needed.

[rogeralsing]

👍🏻

[rogeralsing]

There are some edge cases that needs to be considered here.
e.g. if you try to Watch an actor that is currently terminating, then you immediately get a Terminated message back, at this point the reason for the termination does not exist anymore, it could be a normal stop, or a failure.

The shutdown process needs to be extended to remember the reason for the full lifecycle of the actor to make this work.

Thinking of the best ways to do this w/o widening the state of the actor context.