-
fix(bridge): use live ping cluster id so a stale catalog row can't make a sibling an uplink target
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 0sreleased this
2026-06-21 11:20:11 +03:00 | 119 commits to main since this releaseA node's peer_node_advertise row is stamped once, at join time, by the leader
using the cluster id its handler captured at process start. After a cluster
rename (or when the leader's env id is stale) that row carries the OLD cluster
id while the node actually runs under the new one. The bridge picker copied the
stale catalog id into its sample, so the own-cluster filter (sample.ClusterID ==
myCluster) never matched and the picker shipped replication batches at a
same-cluster sibling — which refuses them with 404 'bridge receiving is not
enabled', stalling the real uplink to the hub.Fixes:
- Picker trusts the LIVE cluster/node id the peer reports over /raft/ping
(X-Raft-Cluster-ID/-Node-ID) over the stored catalog value, so a mis-tagged
same-cluster node is recognised and excluded. Self-healing read-side. - Handler stamps catalog writes (join advertise, peer-remove, leave lookup)
with the live Status().ClusterID instead of the start-time id. - Every node re-advertises itself (followers forward to the leader) with its
own live cluster id, so a follower's row self-corrects without a re-join
(also fixes the intra-cluster metric fanout, which keys on cluster_id).
Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01U3LvJu9qZfspPr21TW9ptvDownloads
- Picker trusts the LIVE cluster/node id the peer reports over /raft/ping