Skip to content

test(bus): deterministic dial-back source probes to decide #61 sufficiency - #69

Merged
hartsock merged 1 commit into
mainfrom
test/dial-back-source-probe
Jul 19, 2026
Merged

test(bus): deterministic dial-back source probes to decide #61 sufficiency#69
hartsock merged 1 commit into
mainfrom
test/dial-back-source-probe

Conversation

@hartsock

Copy link
Copy Markdown
Member

What this PR does

  • Adds three deterministic real-iroh dial-back "source probes" (bus.rs unit
    tests) that answer the empirical #61 question the #[ignore]d mDNS tests
    can't: what does incoming.remote_addr() report for a same-host dial, and does
    reply_dial_candidates actually reconnect to it?
    Each binds two real
    transport endpoints, has the responder observe the source exactly as
    accept_conn does
    , and dials the asker back over the candidate set.
  • probe_loopback_v4/v6_source_is_dialable_and_reconnects — dial over loopback,
    observe + log the source, assert it's dialable and the dial-back reconnects.
  • probe_scopeless_link_local_source_reconnects_via_loopback_fallback — the
    decisive #61 case: the exact fe80::/scope-0 (undialable) shape at the
    asker's real port; assert the candidate set drops it yet still reconnects via
    the loopback fallback over real iroh.

Test plan

  • cargo test -p agent-mesh-bus --lib probe_3/3 green, ~0.06s, deterministic.
  • Observed on this host: loopback-v4 → 127.0.0.1:<port>, loopback-v6 →
    [::1]:<port> (both dialable).
  • just check + just cov-ci green via the pre-push hook (57-test bus lib incl.
    the probes; coverage floor held — these only add coverage).

Out of scope

  • Cross-host scoped link-local (does iroh preserve the recvmsg scope id so a
    scoped fe80:: source is directly dialable?) — genuinely a two-host / real-NIC
    scenario, left to the existing #[ignore]d reply_reaches_quiet_asker_via_dial_back
    real-LAN tier.
  • No production change. #63's fix is untouched; this only adds decision
    evidence.

The decision this informs

For the same-host case (CI + the common quiet-peer scenario), #63's
candidate-set fix is sufficient: the reply is delivered even when iroh
surfaces the undialable scopeless-link-local source — proven deterministically,
end to end. The one remaining open question is cross-host scoped link-local,
which fundamentally needs the real-LAN tier.

🤖 Generated with Claude Code

…iency

WHAT: Three real-iroh unit probes in bus.rs that answer, deterministically, what
the #[ignore]d mDNS integration tests cannot: what does incoming.remote_addr()
report for a same-host dial, and does the reply_dial_candidates set actually
reconnect to it?
  - probe_loopback_v4/v6_source_is_dialable_and_reconnects: bind two real
    endpoints, dial asker->responder over loopback, observe the source exactly as
    accept_conn does (logged as evidence), then dial the asker BACK over the
    candidate set and assert it reconnects.
  - probe_scopeless_link_local_source_reconnects_via_loopback_fallback: the
    decisive #61 case — feed the exact fe80::/scope-0 (undialable) shape at the
    asker's real port; assert the candidate set drops it yet still reconnects via
    the loopback fallback over real iroh.

WHY: #63 landed the candidate-set fix (reply_dial_candidates) but the empirical
"is it sufficient?" question was only answerable on a real-LAN runner. These make
the SAME-HOST answer deterministic and CI-gating: #63 delivers the reply even in
the worst-case scopeless-link-local source shape. Cross-host scoped-link-local
(does iroh preserve the recvmsg scope_id?) remains the real-LAN tier, covered by
the existing #[ignore]d reply_reaches_quiet_asker_via_dial_back.

Observed on this host: loopback-v4 -> 127.0.0.1:<port>, loopback-v6 -> [::1]:<port>
(both dialable); all three probes green in ~0.06s.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@hartsock
hartsock merged commit 16b8a92 into main Jul 19, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant