Skip to content

bug(deploy): preserve verify-skip vs selective-flash outcome in deploy response message #76

@zackees

Description

@zackees

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:

  1. 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.
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions