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.
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:
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 stopclearing 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
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.