bug: fbuild-daemon stays running after autoresearch, causes memory pressure on Windows

[zackees]

Summary

The fbuild daemon process persists after autoresearch completes and accumulates memory. On Windows with limited resources, having the daemon, zccache-daemon, and multiple Python processes running simultaneously causes OSError: [WinError 8] Not enough memory resources are available when trying to compile (cargo build, maturin develop, etc.).

Observed behavior

• fbuild-daemon.exe stays resident at ~58MB after autoresearch ends
• zccache-daemon.exe also stays resident
• Combined with Claude Code's multiple Python processes, the system runs out of process creation memory
• _winapi.CreateProcess fails with WinError 8

Expected behavior

Either:

1. The daemon should have an idle timeout and shut itself down after N minutes of inactivity
2. Or autoresearch should explicitly stop the daemon when it's done (if no other consumers need it)

Workaround

Manual taskkill /F /IM fbuild-daemon.exe before running memory-intensive builds.

Context

Encountered while developing fbuild#50 (adding reset_device() to SerialMonitor). The daemon from a prior autoresearch session was still running and consuming memory when cargo build was attempted.

Related

• feat: FbuildSerialAdapter should support DTR reset for device reboot #50 — DTR reset support (where this was hit)

[zackees]

Root cause fixed and merged in PR #60.

The daemon was staying resident because handle_serial_ws had two error paths after open_port succeeded that returned without tearing down the session: attach_reader returning None, and socket.send(Attached) failing. Both left a SerialSession entry in SharedSerialManager.sessions. attach_reader additionally mutated session.reader_client_ids even on the None-return path, so has_clients() stayed true forever and the 120s self-eviction loop never fired.

Two PRs addressed this:

• fix(daemon): surface self-eviction blocker in logs (#51) #58 — surfaced the blocker at info level (Daemon staying alive: N open serial sessions) so a future regression is observable instead of silent
• fix(daemon): tear down serial session on ws early-return (#51) #60 — extracted cleanup_ws_serial_session() and invoke it on both early-return paths; made attach_reader all-or-nothing so it never leaves a dangling reader id. Regression test in fbuild-serial.

The manual taskkill /F /IM fbuild-daemon.exe workaround should no longer be needed. Closing.