Handling ActorRef Validity Post Actor Restart in Ractor

[tqwewe]

I'm currently using the ractor library in a Rust project and have encountered a scenario that I'd like to discuss and seek guidance on.

Context: I have two primary actors in my application:

1. CommandHandler - Responsible for handling commands and persisting events to a database.
2. OutboxRelay - In charge of relaying events to an external service, such as Redis streams.

The CommandHandler holds an ActorRef to the OutboxRelay for communication purposes. Both actors are supervised and configured to restart upon encountering errors.

Challenge: My concern arises when the OutboxRelay encounters an error and restarts, potentially leading to a change in its ActorRef. This change can render the ActorRef stored in the CommandHandler obsolete or invalid, disrupting the communication flow.

Questions:

1. Does ractor provide a mechanism to ensure that ActorRefs remain valid or are automatically updated post actor restart? If so, could you guide me on how to implement this?
2. In the absence of such a feature, what are the recommended practices to handle such scenarios within ractor?
3. Are there plans to introduce a feature that addresses this issue, or is it worth considering for future development?

I appreciate any insights or suggestions on how to effectively manage ActorRef validity in the face of actor restarts within the ractor framework.

[slawlor]

In your example, is the command handler the supervisor of the outbox relay? If so, then the handler would need to implement handling of the supervision event, and creating the new relay. At which point it would have the new actor reference simply need to store it in its state.

If not, then whoever is the supervisor of the outbox relay would need to notify any actors that hold a reference to the relay that is reference has now changed. An ActorRef only lives for the lifetime of a single actor, and does not persist through restarts.

[tqwewe]

In your example, is the command handler the supervisor of the outbox relay?

In my case, they're both supervised by another process.

If not, then whoever is the supervisor of the outbox relay would need to notify any actors that hold a reference to the relay that is reference has now changed.

Thats what I've done for now, and it works well, however I wonder how difficult it might be to implement actor restarting, so that the ActorRef is maintained and none of this notifying of "this actor ref has changed" needs to be done.

Notifying other processes of a new actorref involves quite a lot of boilerplate, and there's a possibility for messages to fail to send when an actor is restarting.

Adding some kind of mechanism so that the messages can be queued up while an actor is being restarted would be more fault tolerant and also be simpler to handle situations where an ActorRef is stored in multiple places throughout an application.

[slawlor]

The problem is upon an actor's death there's a lot of properties that get dropped. Once something is dropped, specifically stuff like the messaging channel, it's not really recoverable as the message will already have been flushed.

If you really needed something like a restarting actor, something I've seen is where your actor gets a supervisor which is an isolated supervisor for that actor. That's supervisor's referenced doesn't change because it never restarts, however the actor under the hood may crash and restart which is fine. But the parent actor which is doing the supervision flow maintains a constant reference.

You can also include stuff then like message load shedding and other properties similar to a factory of one