You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(daemon): client redials a dead deterministic port — respawn after crash never recovers (split from #1213) #1228
Split from #1213 per the note in PR #1227 ("What part 2 does not fix — stated plainly").
Residual symptom
After a daemon crash, clients kept failing with:
daemon error: request failed: error sending request for url (http://127.0.0.1:52289/api/deploy)
even after the stale port/pid/status records were deleted by hand — the next invocation recreated the same records and redialed the same port. #1227 fixed the records lying about a dead daemon (dead-owner endpoint gating, daemon stop clearing stale records), but as its PR body states, the port is derived deterministically from (version, cache identity) per #1009, so discarding the port file yields the same number. The persistent connection failure is therefore a daemon-respawn failure: after the crash, a new daemon either was not spawned, failed to start, or failed to bind — and the client surfaced only the connection error.
What's needed
Reproduction: crash a daemon (the original trigger was two concurrent ESP32 compiles against one daemon), then trace the next client invocation:
does it attempt a respawn at all after the (now-merged) liveness gate rejects the stale endpoint?
if it spawns, does the new daemon fail to start/bind (port still held in TIME_WAIT? orphaned child? startup panic swallowed)?
capture daemon stdout/stderr/log for the failed start.
Fix: whatever the trace shows — likely making the client's spawn-after-dead-endpoint path robust and surfacing daemon startup failure to the client instead of a bare reqwest connection error.
Test: a regression test that kills a daemon uncleanly and asserts the next client request either reaches a freshly-spawned daemon or reports a specific, actionable startup failure.
Environment (original report)
Windows 10 Pro 19045, fbuild 2.5.2, ESP32-C6 on COM9; trigger was concurrent compiles (#1213 has full context).
Defaults chosen by the drafting agent are listed inline — edit as needed.
Activity
test(cli): pin daemon crash-recovery with a real-process regression t…