audit: blocking operations with no timeout in fbuild-deploy (sub-issue of #802) #804

Intro

Audit of crates/fbuild-deploy/ for blocking operations without a wall-clock cap. This crate spawns external flash tools (esptool, avrdude, lpc21isp, teensy_loader_cli) and, when the espflash-native feature is on, calls into the espflash library directly to talk to ESP32 family chips over USB-CDC. Every flash invocation here is the kind of operation that can hang on hardware misbehavior (board disconnected mid-flash, USB stall, stub flasher wedged), so a missing wall-clock cap is a daemon-hang surface.

Good news: every subprocess spawn in this crate (esptool, avrdude, lpc21isp, teensy_loader_cli) goes through fbuild_core::subprocess::run_command(...) with an explicit Some(Duration::from_secs(...)). The subprocess path is well-covered.

Bad news: the native espflash library path (esp32_native/) has no wall-clock cap on the high-level library calls. The per-read serialport timeout (3 s verify / 10 s write) bounds individual UART reads, but espflash's connect() / checksum_md5() / write_bin_to_flash() / reset_after() can do their own internal retry loops on top of those reads — none of which we bound with tokio::time::timeout(...) or a thread-level deadline. On a wedged USB-CDC stack (the exact case that motivated the audit) those calls can spin for minutes before surfacing an error.

The Teensy state machine has its own bounded poll loops (wait_for_new_cdc_port, wait_for_disappearance, probe) — all OK.

Findings

What was searched

Searched on crates/fbuild-deploy/src/:

• Command::new / \.output\(\) / \.wait\(\) / \.spawn\( → no direct subprocess spawns; everything routes through fbuild_core::subprocess::run_command which takes an explicit Option<Duration>. Every call site in this crate (avr.rs:123, lpc.rs:217, esp32/deployer.rs:330,671,746, teensy/flash.rs:122) passes Some(...). OK.
• espflash:: / Flasher:: / connection\. → see findings above.
• serialport::new → every .timeout(Duration::…) call has an explicit per-read cap (2s reset, 3s native verify, 10s native write, 50ms / 100ms probe paths). Per-read caps are correct; the missing piece is wall-clock caps on the surrounding library calls.
• loop { / while → all such loops in this crate carry an Instant::now() < deadline or attempt < total_attempts bound: teensy/port_discovery.rs:101, teensy/halfkay_probe.rs:45, teensy/first_byte_probe.rs:60, teensy/flash.rs:116, lib.rs:123. OK.
• thread::sleep / tokio::time::sleep → all bounded by an enclosing while deadline or a single fixed-duration backoff after a bounded loop.
• reqwest:: → no matches. This crate does not do HTTP.
• tokio::process:: / \.await → no matches (the deploy paths are sync; the daemon handler does the spawn_blocking).
• \.lock\(\) / RwLock → only in #[cfg(test)] blocks (teensy/soft_reboot.rs:87 TEST_ENV_LOCK, lib.rs:201,217,252,263 ObservableDeployer). No production locks in deploy hot paths.
• post_deploy_recovery → only the default impl in lib.rs:121 and the test override; the documented 3s fast-poll is correctly bounded.

Out-of-scope notes

• Subprocess timeouts elsewhere: fbuild_core::subprocess::run_command itself implements the wall-clock cap via wait_timeout; that crate is being audited separately (the fbuild-core row of audit: blocking operations with no timeout (meta) #802).
• Daemon-side deploy handler: any tokio::time::timeout wrapping at the /api/deploy HTTP boundary is in crates/fbuild-daemon/src/handlers/operations/deploy.rs and is covered by the fbuild-daemon audit row of audit: blocking operations with no timeout (meta) #802.
• fbuild-serial preemption protocol: WebSocket / IPC writes to fbuild-serial during deploy preemption are owned by fbuild-serial and are covered by that crate's audit row.
• reset.rs: uses serialport::new(...).timeout(Duration::from_secs(2)) + short thread::sleep. Bounded, not a finding.
• size_check.rs / method_validation.rs: pure CPU / disk metadata, no blocking I/O.
• esp32/qemu.rs: builds argv only; never spawns QEMU itself (that's daemon-side).
• espflash library version: espflash = "4". If a future version exposes a configurable wall_clock_timeout on Flasher, the suggested tokio::time::timeout wrappers can be replaced with a config knob. Until then the external wrapper is the only way.