-
fix(raft): leader re-asserts cluster auth secret into the log so post-recovery joiners get it
Release / version (push) Canceled after 0sRelease / frontend (push) Canceled after 0sRelease / linux (amd64) (push) Canceled after 0sRelease / linux (arm64) (push) Canceled after 0sRelease / windows (push) Canceled after 0sRelease / macos (push) Canceled after 0sRelease / release (push) Canceled after 0sBuild and Push Docker Image / build-and-push (push) Canceled after 0sLastSkywalker released this
2026-06-21 13:14:56 +03:00 After a wipe-state recovery, the leader's DB keeps the cluster auth secret but the
fresh Raft log it bootstraps does NOT contain a CmdAuthSecretSet entry. A node
joining the recovered cluster replicates the log (no snapshot yet) and never
receives the secret, so it falls back to its own env JWT secret. The intra-cluster
metric stream and cross-node sessions are HMAC'd/signed with that secret, so they
fail with 'signature mismatch' both ways (the hub/bridge keeps working — it uses a
separate secret that is re-published).reconcileClusterSecret read the secret from the local DB, saw it present, adopted
it as a no-op and returned — never re-committing it to the fresh log. Fix: when
leader, re-assert the auth secret into the replicated log once per leadership term
(idempotent upsert), so it reaches every current and future peer. Heals an
already-stuck cluster as soon as the leader runs this code, and prevents the issue
for future recoveries — no re-wipe or manual secret alignment needed.Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01U3LvJu9qZfspPr21TW9ptvDownloads