Akka Cluster Rolling Upgrade and Persistent Actor Event Journal Compatibility

Akka Cluster Rolling Upgrade and Persistent Actor Recovery Interoperability

The goal is to determine whether a failed Akka Cluster rolling upgrade can be recovered without manual intervention when persistent actors have written events using a newer serializer or event definition that older nodes cannot deserialize.

Constraints include the requirement for binary compatibility of messages between cluster nodes, the necessity that Akka Persistence Event Adapters be deployed before any new event types are persisted, and the lack of an automatic rollback mechanism for journal state.

Uncertainty remains around how the cluster can detect incompatible persistent actor state, whether shard allocation with remember‑entities exacerbates the problem, and what health‑check or deployment ordering strategies can guarantee safe recovery.

What deployment ordering ensures that event adapters are available on all nodes before new event types are written? How can the cluster identify and isolate nodes whose persistent actor state cannot be recovered due to version mismatch? Are there recommended health‑check patterns that trigger manual recovery before attempting to restart upgraded nodes?