Summary
POST /api/deploy and fbuild deploy currently collapse multiple distinct ESP32 deploy outcomes into the same top-level message: deploy succeeded.
On a real ESP32-S3 (COM13), I reproduced all of these with the current main binary:
- baseline full flash
- verify-flash skip because the device already matched the requested image
- selective rewrite of only
firmware.bin after changing sketch source while bootloader.bin and partitions.bin stayed byte-identical
In all three cases the top-level response message remained deploy succeeded, even though the daemon/deployer already knows the more specific outcome.
Repro
Hardware:
- Board:
esp32-s3-devkitc-1
- Port:
COM13
- USB mode:
USB-Serial/JTAG
- esptool:
v5.1.0
Fixture:
tests/platform/esp32s3
- baseline image copied to a temp fixture and deployed with
skip_build=true
- alternate image built from the same fixture after changing only the
Serial.println(...) string in src/main.ino
HTTP request body used:
{
project_dir: <fixture>,
environment: esp32s3,
port: COM13,
skip_build: true,
verbose: true,
monitor_after: false,
monitor_show_timestamp: true,
qemu: false,
qemu_timeout: 30,
pio_env: {}
}
Observed responses:
- When the board already matched the requested image,
stdout contained three successful verify-flash digest checks and no write, but message was still deploy succeeded.
- After building an alternate valid firmware where only
firmware.bin changed, stdout showed a write only at 0x00010000, but message was still deploy succeeded.
Expected
The top-level response should preserve the real deploy outcome so callers can distinguish:
- skipped via verify-flash
- selective firmware-only rewrite
- full flash
Actual
message is always deploy succeeded, so CLI/API consumers have to parse stdout to know what happened.
Why this matters
This hides the behavior added in #67 from both humans and automation, even though the daemon already computes it.
Summary
POST /api/deployandfbuild deploycurrently collapse multiple distinct ESP32 deploy outcomes into the same top-level message:deploy succeeded.On a real ESP32-S3 (
COM13), I reproduced all of these with the currentmainbinary:firmware.binafter changing sketch source whilebootloader.binandpartitions.binstayed byte-identicalIn all three cases the top-level response message remained
deploy succeeded, even though the daemon/deployer already knows the more specific outcome.Repro
Hardware:
esp32-s3-devkitc-1COM13USB-Serial/JTAGv5.1.0Fixture:
tests/platform/esp32s3skip_build=trueSerial.println(...)string insrc/main.inoHTTP request body used:
{ project_dir: <fixture>, environment: esp32s3, port: COM13, skip_build: true, verbose: true, monitor_after: false, monitor_show_timestamp: true, qemu: false, qemu_timeout: 30, pio_env: {} }Observed responses:
stdoutcontained three successfulverify-flashdigest checks and no write, butmessagewas stilldeploy succeeded.firmware.binchanged,stdoutshowed a write only at0x00010000, butmessagewas stilldeploy succeeded.Expected
The top-level response should preserve the real deploy outcome so callers can distinguish:
Actual
messageis alwaysdeploy succeeded, so CLI/API consumers have to parsestdoutto know what happened.Why this matters
This hides the behavior added in
#67from both humans and automation, even though the daemon already computes it.