Add method to re-send dispatch states after startup

[Marenz]

No description provided.

[Marenz]

Maybe this? @llucax @ela-kotulska-frequenz

[llucax]

If this is still about recovering for a crashed actor, I would just re-create the receiver by calling running_status_change.new_receiver in the _run() instead of the constructor. This should also fix the issue, right?

[llucax]

This will highlight the warning properly:

Suggested change

	Warning: Usually you don't need to call this method. It is only useful
	when you need to recover the current running state of your actor.
	Warning:
	Usually you don't need to call this method. It is only useful
	when you need to recover the current running state of your actor.

[Marenz]

This should also fix the issue, right?

No, the dispatches are fetched on Dispatch.start(), not on new_receiver(). You don't get a new "current running status" if you create a new receiver

[ela-kotulska-frequenz]

Shouldn't Dispatcher communicate with an actor by channels?

[llucax]

No, the dispatches are fetched on Dispatch.start(), not on new_receiver(). You don't get a new "current running status" if you create a new receiver

I don't understand this. So some actor at some point needs to subscribe to dispatches, they create a new receiver for status changes and start acting on it. Does this mean that with the current design each actor needs to instantiate its own dispatcher to get the proper running states because otherwise only the first actor that gets a receiver gets them?

Otherwise maybe you can explain more precisely what's the exact issue we want to solve here?

Shouldn't Dispatcher communicate with an actor by channels?

Yes, as I said in the other PR I'm OK to leave it as it is for now as a hack, as I guess it will be a while until we support inter-process communication in channels, and we'll probably need to make some adjustments everywhere, but I would at least document that this is a hack and in the future we need to use a channel to send commands to the actor.

[Marenz]

Usually you set up all your receivers and channels before you even call Dispatcher.start().
Once you call start() we fetch all disptaches and inform through the channel (and DispatchManagingActor, at least optionally) all receivers about the current runtime states (whether they should be running right now).

If for any reason the receiving actor (usually that's the DispatchManagingActor, but API users might need more nuanced control for their scenarios) forgets their state and whether they should be running, that method can give them that state again.