Commit Graph

1 Commits

Author SHA1 Message Date
Joseph Doherty 1ec831883c docs(mesh): Phase 2 plan — comm actors + ClusterClient transport
Phase 2 of the per-cluster mesh program: move the three central->node command
channels (deployments, driver-control, alarm-commands) and the deployment-acks
reply channel off DistributedPubSub onto Akka ClusterClient, behind a config
flag.

Recon of both repos turned up three corrections to the design doc's account of
the sister project, all folded into the plan:

- Design doc S2 claims "every unhandled message replies with a typed failure".
  ScadaBridge has no ReceiveAny/Unhandled override in either comm actor; the
  typed-failure idiom fires only for a MISSING REGISTRATION, per message type.
- "No central buffering" was never a setting they wrote. They have zero
  akka.cluster.client HOCON and run the defaults (buffer-size 1000,
  reconnect-timeout off). We choose buffer-size = 0 deliberately.
- Publish -> Send is the wrong substitution. Today's deploy notify is a
  broadcast every DriverHostActor receives (no ClusterId filter exists on the
  node side), so it must become SendToAll. Send would deploy to exactly one
  node of the fleet and seal green on partial acks.

Also records the single-mesh duplicate-delivery trap (one ClusterClient in
Phase 2, not one per Cluster -- a receptionist serves its whole mesh) and one
deviation from the program plan's exit gate: there is no cross-boundary Ask in
Phase 2, because every migrated command is fire-and-forget with a local reply,
so "an Ask timing out cleanly" cannot be run as written.

Marks the program tracking tables current: prereq + Phase 1 are DONE (they
still read "not executed"), Phase 2 in progress.

Claude-Session: https://claude.ai/code/session_01GASWkNEi68FSCtvr6rLoEW
2026-07-22 10:37:37 -04:00