Updates
2 October 2026 — node v0.22.1, client 0.17.0, pi-evolver 0.8.2.
This is an archived entry. See the latest update.
2 October 2026
A second release the same day. Node v0.22.1 carries the monitor fix; the rest is in the client libraries, and the first item is the one that matters.
- A refusal that clients could not read
- v0.22.0 taught a node to refuse a channel body when it has nowhere to put it, and to
say exactly why. That was the right behaviour, but the reason was new, and every client
older than 0.17.0 had never heard of it. An unknown reason is reported
as unknown — which does not mean “refused”, it means
the write may have been ordered, and that is the one answer a caller must never
simply retry. So a clean refusal arrived looking like an unresolved write.
@mcsherrylabs/evolver-client0.17.0 adds the reason andpi-evolver0.8.2 pairs with it, so the refusal now reads as a refusal.
This was not hypothetical. Our own LLM proxy met it and stopped serving for 47 minutes while every health signal stayed green: the container reported healthy, its node stayed in sync, and one unresolved write silently blocked everything queued behind it. If you run an application against Evolver, update its client. A stale client does not fail at start-up — it fails later, as a stall, the first time it meets a reason it predates. - The fleet monitor sees more of the network
- The monitor crawled only nodes advertising a public address, and deliberately had no fallback. Nodes that publish just a peer address were therefore invisible to it, though they answer perfectly well. It now falls back to the peer address, which made four more nodes visible on the live fleet immediately. Nodes that advertise no address at all remain uncrawlable, which is correct — there is nothing to dial.
- Devnet is running v0.22.1
- Upgraded in place rather than rebuilt: the chain was kept, and the block identifiers at rounds 100, 500 and 1000 read identically before and after, which is the cheap proof that a release did not quietly start a new chain. The two database migrations this release carries applied to the running store in 33 ms.