Updates

The hammering is gone

For weeks the logs of every follower node carried a repeating wall of TLS handshake failed…ClosedChannelException and Cannot send message — no connection for nodeId: devnet1-node0. A follower that was not a committee member kept emitting signed NewViews on every Pacemaker timeout. Each one was addressed to the committee, and a node that is not a committee member is not admitted by it — so every NewView became a failed send to devnet1-node0, which in turn triggered an immediate re-dial of a peer that was never going to accept the connection. That is the loop that buried the real errors.

v0.24.5 stops it at the source. broadcastNewView is now gated on committee membership for the round being announced, so a non-member simply does not emit the message there is no one to send it to. The protocol behaviour of the committee is unchanged; what changed is that followers stop talking to a door that was never open to them.

Measured against the retained before

This is a claim about production logs, so it is stated as a measurement rather than a change description. A five-minute window of one follower node was captured before the fix and kept. The same node, the same log patterns and the same duration were then captured after the estate moved to v0.24.5.

A thirty-minute watch across all ten managed nodes followed. The two signals that define the loop — the failed committee sends and the NewView rebroadcasts that produced them — stayed at zero on every one of the six active agent nodes. At the old rate thirty minutes would have produced roughly 1,200 of each, per node. The remaining committee dial attempts are ordinary peer retry back-off, not message-triggered: they are the same probes that were present before the fix, and the committee refuses inbound connections by design, so a follower probing it and backing off is the expected steady state rather than a fault.

Two things are deliberately not claimed. The remaining TLS handshake failed lines are still present, but they are not aimed at the committee at all — they are a private LAN address and an unrelated third-party node the followers discover and probe. And the committee's own [inbound-budget] refusing lines are by design, not a symptom.

Upgrade the complete dependency tree — and redeploy

The release set is node v0.24.5, Meerkat v0.7.16 and scheduler v0.11.33. 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, so nothing done on the box can move them — re-tagging Meerkat and the scheduler against the new node is what actually carries the bump to the front nodes. The published image-digests.yaml inside each artifact is the record, and it now names evolver-node:v0.24.5.

This release also closes the gap left by the previous one. The 15 October rollout moved the committee, the front nodes and the local LLM node, but left the six agent nodes behind and left the installer bundling an older node. v0.24.5 carries every remaining surface: all six agent nodes and their registries were redeployed, every node identity and volume was preserved, and the published installer now bundles node v0.24.5 and Meerkat v0.7.16, so a fresh install cannot land on an old estate.