Conversation
…e to CLI Fixes #130. Root cause (daemon): the `POST /api/test-emu` handler did not construct an `OperationGuard`, so the daemon's 30 s self-eviction loop classified the daemon as "empty" during long (>30 s) ESP32/QEMU builds and forced graceful shutdown mid-request. That tore down the in-flight HTTP connection and surfaced on the CLI as `error sending request for url (.../api/test-emu)` even though the daemon was nominally "healthy" a moment earlier. Root cause (CLI): `run_test_emu` called `std::process::exit(resp.exit_code)` whenever the daemon reported `success=false`. If the daemon (or a proxy) returned `exit_code=0` alongside `success=false`, the CLI silently exited 0 — shells and CI treated the failure as success. Changes: - `handlers/operations.rs` — expose `OperationGuard` as `pub(crate)` so sibling handlers can register operations. - `handlers/emulator.rs::test_emu` — construct an `OperationGuard` at the top of the handler so the self-eviction loop leaves the daemon alone for the full build + emulate lifecycle. - `fbuild-cli/src/main.rs::run_test_emu` — clamp the exit code to ≥1 whenever `success=false`, so daemon failures always surface as non-zero shell exits. Tests: - `crates/fbuild-daemon/tests/test_emu_endpoint.rs` — verifies the route is registered (structured 400 on missing project) and proves the `OperationGuard` is installed via `touch_activity` side-effect. Reverting the emulator.rs fix causes this test to fail with `idle_duration is 60.0001571s`. - `crates/fbuild-cli/tests/test_emu_exit_code.rs` — spawns a mock HTTP daemon that returns `success=false, exit_code=0` and asserts the CLI exits non-zero. Manual repro (Windows): before: CLI printed `error: daemon error: request failed: error sending request for url (http://127.0.0.1:8765/api/test-emu)` with exit 0 after long builds. after: `fbuild test-emu tests/platform/uno -e uno --emulator simavr \ --timeout 5` → "emulator error: ..." + exit 1. `fbuild build tests/platform/uno -e uno` → builds + exits 0. Quality gates: - `uv run cargo clippy --workspace --all-targets -- -D warnings` clean - `uv run cargo fmt --all --check` clean - `uv run cargo test --workspace` 0 failures across 34 test binaries Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 0 minutes and 5 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (7)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Fixes #130.
Summary
On Windows 10 users saw
error: daemon error: request failed: error sending request for url (http://127.0.0.1:8765/api/test-emu)when runningfbuild test-emuagainst a healthy daemon. A second bug made the CLI exit with code 0 even though it had just printederror:.Root cause 1 — daemon tore down the connection mid-request
POST /api/test-emudid not construct anOperationGuard, so the daemon's 30 s self-eviction loop classified itself as "empty" during long (>30 s) ESP32/QEMU builds and triggered graceful shutdown. Graceful shutdown closed the in-flight HTTP connection, and reqwest surfaced that aserror sending request for url.Root cause 2 — CLI exited 0 on daemon failure
run_test_emucalledstd::process::exit(resp.exit_code)whenresp.success == false. If the daemon (or an intermediate proxy) returnedexit_code=0alongsidesuccess=false, the CLI silently exited 0 and CI / shell scripts treated the failure as success.Fix
handlers/operations.rs— exposeOperationGuardaspub(crate).handlers/emulator.rs::test_emu— construct anOperationGuardat the top of the handler (before any early-returns) so the self-eviction loop leaves the daemon alone for the entire build + emulate lifecycle.fbuild-cli/src/main.rs::run_test_emu— clamp exit code to ≥1 whensuccess=false, so daemon failures always surface as non-zero shell exits.Tests
crates/fbuild-daemon/tests/test_emu_endpoint.rs— asserts the route is registered (structured 400 on missing project) and proves theOperationGuardis installed viatouch_activity()side-effect. Reverting the emulator.rs fix causes this test to fail withidle_duration is 60.0001571s.crates/fbuild-cli/tests/test_emu_exit_code.rs— spawns a mock HTTP daemon that returnssuccess=false, exit_code=0and asserts the CLI exits non-zero.Manual repro (Windows 10)
Before:
After:
fbuild build tests/platform/uno -e unoalso builds + exits cleanly after the fix.Test plan
uv run cargo clippy --workspace --all-targets -- -D warningsuv run cargo fmt --all --checkuv run cargo test -p fbuild-daemon(2 new tests pass)uv run cargo test -p fbuild-cli(1 new test passes)uv run cargo test --workspace— 0 failures across 34 test binariesfbuild test-emu tests/platform/uno -e uno --emulator simavr --timeout 5→ non-zero exit + explicit diagnostic🤖 Generated with Claude Code