Summary
fbuild test-emu on Windows 10 returns a connection error to the daemon even when the daemon is confirmed running on 127.0.0.1:8765. Observed against fbuild 2.1.18 attempting to exercise the native QEMU path from FastLED.
Environment
- Windows 10 Pro 10.0.19045, bash shell
- fbuild 2.1.18 (latest PyPI wheel, installed via
uv pip install fbuild)
- Invocation from
C:/Users/niteris/dev/fastled
tests/fbuild_qemu_smoke/ — minimal standalone project (platformio.ini + src/main.ino) included in the FastLED repo
Repro
From the FastLED repo:
uv sync --upgrade-package fbuild # resolves to 2.1.18
uv run fbuild daemon restart # brings up daemon on 127.0.0.1:8765
uv run fbuild daemon status # confirms "daemon is running", state: idle
uv run fbuild test-emu tests/fbuild_qemu_smoke -e esp32dev --emulator qemu --timeout 10
Output:
error: daemon error: request failed: error sending request for url (http://127.0.0.1:8765/api/test-emu)
Notes
- Exit code is
0 — the CLI should exit non-zero on daemon error.
curl http://127.0.0.1:8765/health from the same shell returns HTTP 200 with {"status":"healthy"}. So the daemon is reachable; only test-emu fails.fbuild build <project> -e esp32dev hangs indefinitely with no stdout; had to kill after ~15 min.- On one run
daemon status reported a daemon belonging to a different FastLED worktree (PID mismatch with the one just restarted), state deploying. Concurrent-worktree usage may be at play, but the CLI's own-daemon contract should still honor the status response.
Expected
fbuild test-emu should either (a) build + run the sketch in QEMU and exit on boot marker, or (b) emit a diagnostic pointing at the real blocker (wrong daemon, missing QEMU binary, etc.) with a non-zero exit code.
Impact
Blocks the FastLED ↔ fbuild native-QEMU integration. FastLED PR/branch that adds a smoke test (ci/tests/test_fbuild_qemu.py + tests/fbuild_qemu_smoke/) currently xfails against 2.1.18 on Windows.
Cross-ref
- FastLED change that tracks this: adds
ci/tests/test_fbuild_qemu.py expected to pass once this is fixed.
Summary
fbuild test-emuon Windows 10 returns a connection error to the daemon even when the daemon is confirmed running on127.0.0.1:8765. Observed againstfbuild 2.1.18attempting to exercise the native QEMU path from FastLED.Environment
uv pip install fbuild)C:/Users/niteris/dev/fastledtests/fbuild_qemu_smoke/— minimal standalone project (platformio.ini+src/main.ino) included in the FastLED repoRepro
From the FastLED repo:
Output:
Notes
0— the CLI should exit non-zero on daemon error.curl http://127.0.0.1:8765/healthfrom the same shell returns HTTP 200 with{"status":"healthy"}. So the daemon is reachable; onlytest-emufails.fbuild build <project> -e esp32devhangs indefinitely with no stdout; had to kill after ~15 min.daemon statusreported a daemon belonging to a different FastLED worktree (PID mismatch with the one just restarted), statedeploying. Concurrent-worktree usage may be at play, but the CLI's own-daemon contract should still honor thestatusresponse.Expected
fbuild test-emushould either (a) build + run the sketch in QEMU and exit on boot marker, or (b) emit a diagnostic pointing at the real blocker (wrong daemon, missing QEMU binary, etc.) with a non-zero exit code.Impact
Blocks the FastLED ↔ fbuild native-QEMU integration. FastLED PR/branch that adds a smoke test (
ci/tests/test_fbuild_qemu.py+tests/fbuild_qemu_smoke/) currently xfails against 2.1.18 on Windows.Cross-ref
ci/tests/test_fbuild_qemu.pyexpected to pass once this is fixed.