fix(mesh): a peer send sweeps every shared network, not one slot's guess - #188
Merged
Merged
Conversation
The tech's KVM Site door opened a browser tab onto a tunnel that never carried a byte - and fleet KVMs have shown the same "online, wired up, nothing connects" ghost before. Root cause, finally: peer_networks is a single slot per peer, overwritten by EVERY inbound frame, and a KVM is multi-homed by design - fleet mesh, local-claim, CEC help mesh at once, broadcasting presence on all of them. The slot therefore names whichever mesh delivered the last advert, which (hub topologies especially) is not necessarily a mesh that carries OUR frames back. send_control then made exactly one attempt on that guess: a route offer into the void, so the site tunnel never activated. Remote control survived only because a live session's inbound frame firehose keeps re-pinning the slot to the session's mesh - the quiet site plane had no such luck. The KVM's Go bridge already ships the cure for its own replies (sendSiteFrame: "we broadcast across our networks... the correct network's send reaches them and others are harmless no-ops"). Mirror it on the node side: - send_control now walks ordered_send_candidates - the slot's network (last proven), then the primary, then every other joined network - and returns on the first daemon-CONFIRMED delivery. - The confirming network is written back to the slot (note_peer_network), so the media frames that follow a route offer (site tunnel bytes, input) ride the mesh that provably reaches the peer, not the last one a presence advert happened in on. - The order lives in a pure fn with a test, like seed_peer_networks. Every send_control caller inherits the sweep: site route offers, the display/input offers, claim, ownership, fleet-key handoff, upgrade asks. cargo test --lib: 155 passed. clippy -D warnings: clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YYdqmManehKSKxwzcfeeU4
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
Field report after #187: the tech's Site door now opens — but the tunnel never carries a byte. Same ghost fleet KVMs have shown before ("online, wired up, nothing connects").
Root cause.
peer_networksis a single slot per peer, overwritten by every inbound frame (handle_channel). A KVM is multi‑homed by design — fleet mesh, local‑claim, CEC help mesh at once — and broadcasts presence on all of them, so the slot names whichever mesh delivered the last advert, which (hub topologies especially) is not necessarily a mesh that carries our frames back.send_controlthen made exactly one attempt on that guess: a site route offer into the void, tunnel never activates, browser spins. Remote control kept working only because a live session's inbound frame firehose keeps re‑pinning the slot to the session's mesh — the quiet site plane had no such luck. (The oldrefresh_peer_networkscomment describes this exact class; the seeding fix filled gaps but left the one‑slot lottery.)The fix mirrors the KVM's own Go bridge, which already ships the cure for its replies (
sendSiteFrame: "we broadcast across our networks… the correct network's send reaches them and others are harmless no‑ops"):send_controlwalksordered_send_candidates— the slot's network (last proven) → primary → every other joined network — returning on the first daemon‑confirmed delivery.note_peer_network), so the media frames that follow a route offer (site‑tunnel bytes, input) ride the mesh that provably reaches the peer.seed_peer_networks.Every
send_controlcaller inherits the sweep: site route offers, display/input offers, claim, ownership, fleet‑key handoff, upgrade asks.Release note
This is node‑side — it ships in the
allmystuff-servethe apps embed. It should ride the v0.2.46 cut alongside #185/#186/#187 (CECSupport #45 already pre‑pins v0.2.46; the KVM needs no change — its side already swept).Verification
cargo test --lib(node): 155 passed, including the newordered_send_candidates_tries_slot_then_primary_then_the_restcargo clippy --lib -- -D warnings: cleancargo fmt: applied🤖 Generated with Claude Code
https://claude.ai/code/session_01YYdqmManehKSKxwzcfeeU4
Generated by Claude Code