How to understand "the actor itself is the state"? Can I resume or restart from a panic?

[hanekoo]

As titled.

Currently, I have two connected actors (A --linkd--> B). The A actor can get a PanicError (not None) from the B actor. At the same time, I don't want the B actor to stop. Instead, I want to restart the B actor without creating a new one.

Is Kameo considering supporting exposing APIs for manually managing actor lifecycles?

[tqwewe]

Actor B in your example can be restarted by returning None from its Actor::on_panic implementation. This way, it kind of supervises itself

[hanekoo]

This might not be the right approach, as it introduces some breaking changes, and it only involves some minor adjustments：hanekoo@699d65a

[tqwewe]

I'm not sure I understand what this commit changes exactly. It allows the actor to return an ActorStopReason, but also false to not stop the actor? it seems a little confusing to return an ActorStopReason but not stop the actor

[hanekoo]

The expectation is as follows:

• Using the panic_and_stop flag to decide whether to stop the actor.
• Return ActorStopReason and pass it to actor_ref.signal_link_died(..).

The above changes did not involve link_died( the second piont) ,just merely proposed the idea of manually controlling the actor's lifecycle internally.

When I saw the actor itself is the state, I guessed that Kameo deliberately avoided exposing interfaces for manually controlling the lifecycle from the very beginning of its design. To be precise, it's about the state interface.

I would like to know if there are similar plans in the future.

[tqwewe]

I would like to know if there are similar plans in the future.

I'm not sure what plans you are referring to exactly. I don't have many plans to change kameos implementation drastically at this point as I'm pretty happy with how its working currently, unless there's some strong reason to do so.

[hanekoo]

Yes, I completely agree. Kameo manages to support asynchronous features while maintaining a clean API, and adding new features should be done cautiously. However, the "supervises" feature is somewhat weak (whether for itself, between actors, or at a more granular level). I'd like to explore some possibilities, but I haven't yet thought of a particularly elegant implementation.