> once message delivery is guaranteed to be in-order and lossless, then for the above scenario the issue is 'obviously' on the sender side.
It depends on how the receiver handles incoming messages:
* there could be a scheme where a message is lost if it isn't handled in the current actor's state (or if it isn't deferred explicitly);
* there could be a scheme where a message that is not handled in the current state is deferred automatically (for example, Erlang's selective receive).
The problem I described exists for the first case but isn't actual for the second. However, schemes with selective receive can have their own drawbacks.
> it can be easily solved with timers where 'A' expects to move from state-a to state-b in say 'n' seconds after startup etc.
The main problem is: a developer should understand that problem and should implement that in code. But people make mistakes...
It depends on how the receiver handles incoming messages:
* there could be a scheme where a message is lost if it isn't handled in the current actor's state (or if it isn't deferred explicitly);
* there could be a scheme where a message that is not handled in the current state is deferred automatically (for example, Erlang's selective receive).
The problem I described exists for the first case but isn't actual for the second. However, schemes with selective receive can have their own drawbacks.
> it can be easily solved with timers where 'A' expects to move from state-a to state-b in say 'n' seconds after startup etc.
The main problem is: a developer should understand that problem and should implement that in code. But people make mistakes...