{
  "summary": "Recovered the named IPv6 diagnostic memory and both issue histories. Historical evidence establishes dead IPv6 discovery reachability and adapter-disable recovery, not synchronous Tokio worker blocking. IPv4-only QUIC binds do not, from this historical evidence alone, establish that every discovery/HTTPS path is IPv4-only. #30 and #174 are distinct prolonged outbound-dial failures, not proof of today's periodic runtime freezes.",
  "files": [
    {
      "path": "C:/Users/decid/.claude/projects/C--Users-decid-Documents-projects-spt-core/memory/broken-ipv6-poisons-iroh-discovery.md:12-20",
      "description": "Primary contemporaneous diagnostic memory: failed discovery IPv6 TCP reachability, working IPv4, adapter-wide IPv6 disable immediately restored join."
    },
    {
      "path": "docs/design/robust-wan-subnet-join.md:9-18",
      "description": "Original incident's 30-second rotating identity, 75-second search deadline, approximately 90-second accepted token window, and network discriminants."
    },
    {
      "path": "docs/adr/0030-robust-wan-subnet-join.md:21-41",
      "description": "Chosen remedies: meet-before-code, per-family bind gate and overrides, explicit failure reporting; periodic family reevaluation deferred."
    },
    {
      "path": "CHANGELOG.md:2722-2741",
      "description": "v0.17.0, 2026-06-28, records shipping family gating, overrides, two-phase join and diagnostic improvements."
    },
    {
      "path": "CHANGELOG.md:1113-1116",
      "description": "v0.53.0 separately records fixing accumulated unfinished work after network changes; not evidence #174 endpoint-recreate recovery shipped."
    },
    {
      "path": "https://github.com/BigscreenVR/spt-bs-releases/issues/30",
      "description": "Prolonged same-millisecond outbound dial failures and misleading remote-peer attribution; one follow-up comment."
    },
    {
      "path": "https://github.com/BigscreenVR/spt-bs-releases/issues/174",
      "description": "NIC-bounce endpoint wedge, same-binary daemon-restart discriminant, and later correction separating ENLYZEAM's transient outage."
    }
  ],
  "architecture": "Historical layers must stay separate: public rotating rendezvous identity → iroh discovery (dns.iroh.link, distinct from relay) → transport establishment → pairing ceremony. The shipped family gate addresses endpoint binding. The historical operator experiment disabled IPv6 across the adapter, a broader intervention. Neither historical issue identifies a specific synchronous call occupying NetHost's workers.",
  "report": "## Original measured mechanism\nFACT — The named memory records SCELTOUIN on 2026-06-27 resolving AAAA but failing TCP 443 to dns.iroh.link's IPv6 address while IPv4 succeeded; disabling IPv6 on the active adapter made joining succeed immediately. Relay reachability was healthy and explicitly distinguished from discovery reachability. Clock offset was +0.09 seconds; firewall and NTP were checked. Source: C:/Users/decid/.claude/projects/C--Users-decid-Documents-projects-spt-core/memory/broken-ipv6-poisons-iroh-discovery.md:12-18.\n\nThe memory attributes the join failure to dead-family attempts silently consuming rotating rendezvous validity. Bounds documented in docs/design/robust-wan-subnet-join.md:10-18: identity rotates every 30 seconds, ±1 token window approximately 90 seconds, search deadline 75 seconds. These are application discovery/search bounds, NOT measured durations of a synchronous OS call or proof of worker starvation. No worker stacks, canary latency or two-worker saturation measurements are present.\n\n## Remedies already shipped\nFACT — v0.17.0 (2026-06-28) shipped family reachability gating and SPT_DISABLE_IPV6/SPT_DISABLE_IPV4; meet-before-code prevents entered codes aging during discovery; progress, verbose diagnostics and surfaced terminal failures remove silent join exhaustion (CHANGELOG.md:2722-2741). ADR-0030:29 scopes the decision to which families the iroh endpoint binds; ADR-0030:41 explicitly defers periodic reevaluation. Historical documentation's 'once at startup/restart' wording must not override today's source showing per-bind probing.\n\nOther historical remedies are narrower than this incident: CHANGELOG.md:2703 records seeded last-known direct dialing for WAN sends plus actual receiver acknowledgments; CHANGELOG.md:1113-1116 records v0.53.0 fixing accumulated unfinished work following network changes. Neither proves that every cold rendezvous discovery path is gated nor that #174's endpoint-recreation proposal shipped. Both requested issues currently remain OPEN in the retrieved issue records.\n\n## #30: shared local failure signature, not identified blocking primitive\nFACT — [issue #30 body](https://github.com/BigscreenVR/spt-bs-releases/issues/30) records 762 failures across seven peers, batches sharing the same wall_ms, 10-second submit-dial bounds recurring roughly every 55 seconds, while pairing beacons continued every 30 seconds. The report infers a shared local submission/release gate rather than seven independent remote failures. This is diagnostic inference in the issue, not a located mutex/syscall.\n\nFACT — [2026-07-30 comment](https://github.com/BigscreenVR/spt-bs-releases/issues/30#issuecomment-5125674180) records last-success to all-failing transition in 35.1 seconds, registry admissions continuing 6.18 hours beyond last successful dial, and approximately 11h48m wedged. The commenter explicitly says 'Reported, not diagnosed.' No IPv6 A/B experiment or runtime-worker trace is recorded. Therefore do not cite #30 as proof that IPv6, discovery, or a particular synchronous blocker caused it.\n\n## #174: endpoint survives bounce but becomes unusable\nFACT — [primary 2026-08-08 evidence comment](https://github.com/BigscreenVR/spt-bs-releases/issues/174#issuecomment-5227486794) records a long-lived HFENDULEAM binder spanning a NIC/profile flap, 752 quic-connect failures across all six targets and relay/Tailscale/LAN paths, healthy ICMP and relay TCP443, no healing from brain restart, and recovery within approximately five minutes after a whole-daemon restart on the SAME v0.55.0 binary. The outage lasted approximately 41 hours. Proposed fix: interface-change or sustained-all-fail triggers recreate/rebind the endpoint in-process. This is a ruled proposed remedy, not a shipped-fix report.\n\nIMPORTANT CORRECTION — [2026-08-17 corroboration comment](https://github.com/BigscreenVR/spt-bs-releases/issues/174#issuecomment-5320033507) says ENLYZEAM spontaneously recovered on its original pre-flap binder and had NO local profile-change event in the implicated window. The initial body grouped ENLYZEAM with the wedge; the later comment distinguishes its transient outage from HFENDULEAM's local-bounce persistent endpoint wedge. Do not repeat the earlier stronger ENLYZEAM claim without this correction.\n\n## Relevance to today's rotation-aligned canary spikes\nINFERENCE — Broken IPv6 remains a plausible NETWORK-DISCOVERY contributor despite IPv4-only QUIC binds if an independent discovery/HTTPS/resolver path can still attempt IPv6. The historic decisive experiment disabled IPv6 for the entire adapter, whereas the shipped remedy is documented as controlling endpoint bind families. These interventions are not logically equivalent. Establishing that current discovery actually retains such a path belongs to today's dependency/source review, not these historical records.\n\nNOT PROVEN — Historical evidence does not establish a synchronous blocking operation, its caller/runtime relation, a 5–10-second lower/upper bound, both-worker occupation, or why active_dial_tasks is zero during today's stale canary. An ordinary asynchronous dead-network timeout need not stall an unrelated canary. The original 30-second number describes rotating rendezvous identity and code freshness; it is not a measurement of periodic whole-runtime freezing. #30/#174 describe hours-long all-peer outbound failure, not recurrent seconds-long post-rotation stalls.\n\nFALSIFIER / REMEDY BOUNDARY — A current source trace showing all implicated discovery traffic truly excludes IPv6 would falsify this proposed surviving dead-family path. A runtime trace showing only nonblocking pending I/O with workers otherwise runnable would falsify dead IPv6 alone as the canary-starvation explanation. Conversely, locating independent IPv6-capable discovery only establishes exposure, not worker blocking. Do not prescribe repeating the already-shipped bind gate, adapter-wide disable, or #174-style recreation as the fix for #302 without identifying the currently blocking operation and affected layer.\n\nAccess/provenance: public issue URLs returned 404; authenticated issue://BigscreenVR/spt-bs-releases/{30,174} reads supplied full bodies and comments. Named memory recovered directly from its local file; no memory:// retry, remote host access, product edits, builds, tests, or validation commands."
}