Updates

The tip-gossip retry storm, and the root cause

A node that was refused before TLS — say, by an inbound budget that was already full — emitted neither a NewPeer nor a PeerDisconnected event. The tip-gossip manager maintained its set of subscribeable peers by summing those two deltas, so a peer lost silently would keep being chosen as the single currentUpstream, probed, dropped, and re-chosen, over and over at roughly the block time. On devnet that produced tens of thousands of TLS handshake failed…ClosedChannelException lines over three days, burying the real errors. A lossless resolver close and a full mailbox each dropped an event the same way.

Reconcile against the live-connection snapshot

The subscribe-side peer set is now derived, at selection time, from the authoritative LiveConnections snapshot — the whole-state, single-writer map the connection tracker already publishes and the P2P messenger already reads. Because that snapshot is recomputed rather than accumulated, it cannot drift. The NewPeer/PeerDisconnected events became triggers that re-run selection instead of accumulators. An upstream that is no longer live is simply no longer selected, and the dial-on-demand retry loop has nothing to re-trigger.

The serve-side subscriber set is unchanged: it is fed by inbound subscriptions, not by connection lifecycle. Only subscribe-side selection moved.

Verification

The full containerised regression suite passed all 33 stages with a clean exit-zero run on the tagged commit — including the connectivity, inbound-budget and committee-dial stages closest to this change. The tag pipeline for evolver-node, evolver-explorer and fleet-monitor was green. In production, every follower now shows the healthy tip-gossip cadence (a re-probe on the order of the block time) instead of the storm. The sibling delta-trackers that share the same defect — the sync manager, the channel overlay and the content-cache manager — are filed as follow-ups (issues 157, 158 and 159) and are not changed by this release.

Upgrade the complete dependency tree — and redeploy

The release set is node v0.24.4, Meerkat v0.7.15 and scheduler v0.11.32. The client stays at 0.19.1; this is a node-only patch, so no SDK or npm release was needed.

A node bump is not finished until its downstream applications follow. The front-node applications pin the node image by digest when their deployment artifact is published — nothing done on the box can move them. So part of this release was re-tagging Meerkat and scheduler against the new node version and redeploying both front nodes from the fresh artifact. Leaving that second half out would leave the estate only half upgraded.

Deployment update, 15 October 2026: every active managed node now runs v0.24.4 — the committee, both front nodes, the local LLM node, explorer and monitor. The committee shows its two front nodes as outbound peers, and identities, keys, channels and data volumes were preserved. The six agent stacks are the maintainer's to cycle and were left at v0.24.3, unchanged by this patch.