grenadeandClaude Opus 5
e7cfe42881
Peer count, transactions in its pool, upload, download and state cache — the volatile half of the feed, decoded from `NodeStatsUpdate`, `NodeHardware` and `NodeIOUpdate`, plus the first values `AddedNode` itself carries so a freshly announced node reads correctly rather than waiting for an update frame. **Never persisted, and the shape says so.** These live in `NodeActivity`, held in memory and attached to the miner route only when the feed is currently reporting the node — a node answered from the cache gets its hardware and no activity at all. A peer count from an hour ago is not a peer count, and storing one would turn a live reading into a stale number that still looks live. Only the newest sample of each series is kept. The feed sends rolling arrays and already redraws them; this is a readout, not a chart. `NodeHardware` carries three parallel series and the third is the feed's own x-axis, which is why the test asserts the download figure is not the timestamps. An update naming a node the feed has not introduced is dropped rather than counted a decode error: a feed joined mid-stream sees these before the `AddedNode` that explains them, and it will be re-sent. Bandwidth renders in decimal units while memory and state cache render in binary. That is not an inconsistency — a reader comparing bandwidth against a NIC or a speed test is comparing against decimal, and one comparing memory against what they bought is comparing against binary. Verified against the live feed: 34 peers, 103 kB/s up, 20.5 kB/s down, 528 MiB of state cache, read off mainnet and rendered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jp6a8EDar9ueEhAxzep4V5