bus: reply dial-back to a scopeless link-local IPv6 source fails; quiet-bind clients become unreachable

[hartsock]

Summary

agent-mesh-bus/src/bus.rs::dial_reply_peer (introduced in #21, "ship replies via dial-back on the request's source address") dials a reply back to the request's source socket address. When that source is a link-local IPv6 (fe80::…) with no scope_id — which is exactly what mDNS surfaces on a CI runner and most Linux hosts — the QUIC send fails:

sendmsg error: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }
  dst=[fe80::…]:PORT

Dial-back then falls through to mDNS. But for a quiet-bind client (BusOptions { announce: false }) there is no mDNS record, so the reply is lost.

Impact

• newt-mesh/tests/conversation_contract.rs::quiet_client_gets_replies_via_dial_back fails deterministically on hosts whose mDNS announces a link-local IPv6.
• Red on newt-agent's nightly Mesh-integration and inherited by any newt-agent PR touching the seam paths (newt-core/**, …) — currently blocking newt-agent PRs #1112/#1113 (unrelated dormant code that merely trips the path filter).
• On agent-mesh@main (237aa1d): dial_reply_peer (line ~607) still does endpoint.dial(pubkey, [addr]) with the single source addr, no loopback augmentation and no scope handling. No later commit addresses it.

Root cause

dial_reply_peer dials the single source addr. dial_peer already augments its candidate set with loopback (same-host works without a relay); dial_reply_peer does not — so a same-host quiet client whose only advertised path is a scopeless fe80:: is unreachable.

Proposed fix

• Minimal (greens the test + real same-host use): in dial_reply_peer, include loopback at the source port alongside the source addr — endpoint.dial(pubkey, [addr, (V4_LOOPBACK, addr.port()), (V6_LOOPBACK, addr.port())]) — mirroring dial_peer's existing loopback rationale. iroh races them; loopback answers for same-host.
• Robust (cross-host correctness): capture the recv interface's scope_id and attach it to link-local dial-back destinations.

Coordination

Filed by Claude, authorized by Shawn, who is notifying the agent-mesh agent directly. A fix PR (minimal version, verified against the contract test in an isolated side-by-side worktree) is incoming and will reference this issue. Checked #58 (session-streams ADR), #59 (synchronous handler registration de-flake), #60 (docs) — no overlap with this transport fix.

[hartsock]

Verification findings — recommend the transport owner take the fix

I reproduced this cleanly (isolated quiet_client_gets_replies_via_dial_back → 30s timeout, sendmsg to fe80::… InvalidInput) in a side-by-side worktree (newt-mesh@main + agent-mesh@main) and tried the minimal dial_reply_peer patch. Results were inconsistent enough that I'm not comfortable pushing a fix into the transport without your eyes:

• Keep the fe80:: source + add loopback to the candidate set → isolated quiet_client passes (0.9s), but the full serial conversation_contract suite still failed on it (racy — the fe80:: attempt is still in the iroh race and can abort/stall the dial).
• Drop the scopeless fe80:: source, dial loopback only → isolated quiet_client regressed to failing, and the sendmsg to fe80:: still fires (so it's also coming from the request-path dial_peer/mDNS candidates, not only dial_reply_peer).

That regression-on-drop is the tell: iroh appears to need/reuse the source path, so the real fix is probably upstream of dial-back — preserve the recvmsg scope_id on the request's source SocketAddrV6 so the link-local destination is dialable, rather than patching dial_reply_peer. That's your area (you own the transport + the #21 change + the iroh path model), and it needs a clean runner to verify — my dev host's real-mDNS/QUIC state degrades across repeated runs, confounding the full-suite signal.

Handoff: root cause + repro are solid (above + issue body). The candidate dial_reply_peer loopback patch is on branch fix/dial-back-loopback-linklocal in the local agent-mesh checkout if useful as a starting point, but I'm not opening a PR from it — it's not cleanly verified and the scope_id approach is likely more correct. Over to you. (Shawn authorized me to dig in and is looping you in directly.)

[hartsock]

Resolved

The reported failure — a quiet-bind (announce: false) client becoming unreachable because dial-back sent the reply to a single scopeless link-local IPv6 source — is fixed and verified:

• fix(bus): dial replies over a candidate set, drop scopeless link-local (#61) #64 — the fix. dial_reply_peer no longer dials one address. reply_dial_candidates builds a fingerprint-keyed candidate set (source path + same-host loopback) and drops the undialable scopeless link-local (fe80::, scope_id == 0) so it can't poison the dial race. The quiet-bind client is reached via the loopback fallback.
• docs: floating-identity doctrine — locations are candidates, never load-bearing #63 — the doctrine. Floating identity: locations are candidates, never load-bearing. The single-address dial shape (dial_reply_peer(pubkey, [one addr])) that caused this is retired by design, not patched.
• test(bus): deterministic dial-back source probes to decide #61 sufficiency #69 — the proof. Three deterministic real-iroh probes decide sufficiency for the same-host case (which is CI and the common quiet-peer scenario). The decisive one feeds the exact #61 shape — a scopeless fe80::/scope-0 source at the asker's real port — and shows the candidate set drops it yet still reconnects over loopback, end to end. #59 (synchronous handler registration) independently removed the serial-suite flakiness the original candidate hit.

Residual (not this bug)

The only open thread is cross-host scoped link-local — whether iroh preserves the recvmsg scope_id so a scoped fe80::%iface source is directly dialable. That's fundamentally a two-host / real-NIC scenario, already covered by the #[ignore]d real-LAN tier (reply_reaches_quiet_asker_via_dial_back). If it ever bites in practice, a fresh narrow issue should track it — it's not the quiet-bind-unreachable failure this issue reported.

Closing as resolved.