audit: blocking operations with no timeout in fbuild-cli + fbuild-python (sub-issue of #802) #810

Sub-issue of #802.

Intro

Audit of crates/fbuild-cli/ and crates/fbuild-python/ for blocking operations without a wall-clock deadline. These two crates are the user-facing entry points: every interactive CLI invocation and every FastLED Python integration funnels through them, so an unbounded blocking op here translates to a hang in front of the user with no signal that anything is wrong.

Overall picture is good — the main DaemonClient in fbuild-cli/src/daemon_client.rs has per-endpoint .timeout(...) calls on every HTTP request, the broker / daemon-spawn poll loops are bounded to 100 iterations of 100 ms (= 10 s wall-clock cap), and outcome::send_op{,_async} in fbuild-python forward a caller-supplied timeout to reqwest. The findings below are the spots that fell out of that pattern.

Findings

Out-of-finding patterns confirmed safe

• All 14 named endpoints on DaemonClient (health, health_full, list_devices, daemon_info, lock_status, device_status, device_lease, device_release, device_preempt, clear_locks, cache_stats, run_gc, deploy, monitor, test_emu, build_streaming) all carry .timeout(...). The Client itself also has a 100 ms .connect_timeout(...) to fail fast when the daemon isn't running.
• fbuild-python/src/outcome.rs (send_op / send_op_async) forwards a caller-supplied timeout: f64 to reqwest; both DaemonConnection and AsyncDaemonConnection default to 1800 s for build/deploy/monitor — caller-tunable, properly bounded.
• fbuild-python/src/json_rpc.rs (read_lines_async / wait_for_remote_json_rpc_response_async / write_async): every source.next() is wrapped in tokio::time::timeout, and the outer while Instant::now() < deadline enforces a wall-clock cap.
• fbuild-cli/src/daemon_client.rs::ensure_daemon_running (broker + direct paths): both for _ in 0..100 { sleep(100ms); ... } loops are wall-clock bounded to 10 s; the direct path also has a [0.0s, 0.5s, 2.0s] backoff over 3 attempts.
• fbuild-cli/src/cli/show.rs:39-57 (tail -f follow loop) is intentionally infinite (user Ctrl+C exit) — not a finding.
• fbuild-cli/src/mcp/server.rs stdin-driven loop is an interactive server lifecycle, not a hung-op risk.
• fbuild-cli/src/cli/serial_probe.rs:250 (while Instant::now() < deadline) is properly bounded.

What was searched

Greps under crates/fbuild-cli/src/ and crates/fbuild-python/src/:

• reqwest:: / Client::default / Client::builder / \.timeout\(
• \.send\(\) / \.recv\(\) / connect_async / TcpStream::connect
• loop \{ / while / for .* in / thread::sleep / tokio::time::sleep
• Command::new / \.output\(\) / \.wait\(\) / \.spawn\(\)
• pyo3 / pyo3_async_runtimes / block_on
• Mutex::lock / RwLock / \.lock\(\)
• daemon_client / connect_daemon / spawn_daemon_process / ensure_daemon_running / ensure_running_via_broker_*
• file-by-file read of daemon_client.rs, serial_monitor.rs, async_serial_monitor.rs, daemon.rs, outcome.rs, json_rpc.rs, daemon_cmd.rs, show.rs, clang_tools.rs, port_scan.rs, serial_probe.rs, build.rs, pio.rs.

Out-of-scope notes

• The running_process::broker::{BrokerSession,AsyncBrokerSession}::adopt(...) call in both fbuild-cli/src/daemon_client.rs:701 and fbuild-python/src/daemon.rs:191, 232 is provided by an external crate (zackees/running-process) and is not part of this audit area. If adopt() itself can hang, that is an upstream concern and should be filed against running-process.
• tokio_tungstenite::connect_async ultimately reaches into tokio::net::TcpStream::connect — this audit treats the connect_async site as the boundary because that is where this crate's code can apply tokio::time::timeout.
• fbuild_core::subprocess::run_command itself accepts an Option<Duration> and already implements the timeout-and-kill protocol correctly — findings here are about call sites that pass None, not about the helper.