Summary
The cascade reported and closed in #284 (daemon/doctor hang + process pileup + wire_send peer_unknown on a VERIFIED peer) recurs on a clean wire 0.16.0. #284 was filed during a 0.15.0→0.16.0 mid-session upgrade; this report is steady-state 0.16.0, so the fixes are either incomplete or regressed.
Environment:
- OS: Windows 10 Pro (19045)
- Binary:
C:\Users\Willard\.local\bin\wire.exe, wire 0.16.0
- Relay: https://wireup.net
- Host: Claude Code MCP integration (session-keyed
WIRE_HOME)
Observed (this session)
Process pileup (#284 §2): Get-Process wire showed 38 wire.exe:
- ~23 ×
wire daemon --interval 5 (should be 1) — one runaway at 134 CPU-s
- 14 ×
wire mcp (stacked across resumes; each boot appears to auto-start a daemon → cascade)
- 1 ×
wire monitor --json, 1 × hung wire doctor
Root cause looks like: each wire mcp startup ensures/spawns a daemon, and nothing reaps prior ones → N resumes ⇒ N daemons contending on relay.lock/slot files ⇒ MCP calls crawl (multi-second). Killing the 21 surplus daemons + restarting a single one (wire up) restored sub-second MCP latency immediately.
wire doctor hangs (#284 §1): wire doctor produced zero output and never returned; had to kill it (it reported exit 127 on kill). The diagnostic command still hangs on the unhealthy condition it is meant to diagnose.
wire_send → peer_unknown on a freshly VERIFIED peer (#284 §6): Right after wire_accept returned status: bilateral_accepted for peer velvet-ember, the next wire_send to that peer returned:
"status":"peer_unknown","reason":"peer 'velvet-ember' not pinned — run `wire dial ...`"
wire_accept reported success but did not leave the peer in a send-pinnable state; an explicit wire_dial velvet-ember@wireup.net was required before wire_send would deliver. Accept and the send-side pin set are out of sync.
Expectation
Cross-ref: identity-split issue #351 (the WIRE_HOME / DID drift that compounds the pileup).
Summary
The cascade reported and closed in #284 (daemon/
doctorhang + process pileup +wire_send peer_unknownon a VERIFIED peer) recurs on a clean wire 0.16.0. #284 was filed during a 0.15.0→0.16.0 mid-session upgrade; this report is steady-state 0.16.0, so the fixes are either incomplete or regressed.Environment:
C:\Users\Willard\.local\bin\wire.exe, wire 0.16.0WIRE_HOME)Observed (this session)
Process pileup (#284 §2):
Get-Process wireshowed 38wire.exe:wire daemon --interval 5(should be 1) — one runaway at 134 CPU-swire mcp(stacked across resumes; each boot appears to auto-start a daemon → cascade)wire monitor --json, 1 × hungwire doctorRoot cause looks like: each
wire mcpstartup ensures/spawns a daemon, and nothing reaps prior ones → N resumes ⇒ N daemons contending onrelay.lock/slot files ⇒ MCP calls crawl (multi-second). Killing the 21 surplus daemons + restarting a single one (wire up) restored sub-second MCP latency immediately.wire doctorhangs (#284 §1):wire doctorproduced zero output and never returned; had to kill it (it reported exit 127 on kill). The diagnostic command still hangs on the unhealthy condition it is meant to diagnose.wire_send→peer_unknownon a freshly VERIFIED peer (#284 §6): Right afterwire_acceptreturnedstatus: bilateral_acceptedfor peervelvet-ember, the nextwire_sendto that peer returned:wire_acceptreported success but did not leave the peer in a send-pinnable state; an explicitwire_dial velvet-ember@wireup.netwas required beforewire_sendwould deliver. Accept and the send-side pin set are out of sync.Expectation
wire doctormust bound its relay-touching probes and print local state on timeout (never hang).wire_acceptmust leave the peer fully send-pinned (no separatewire_dialneeded) — accept and pin should be atomic.Cross-ref: identity-split issue #351 (the WIRE_HOME / DID drift that compounds the pileup).