Compressed write_flash fails deterministically mid-image on ESP32-S3 (status 201 at ~75%) #255

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate
• Read the documentation to confirm the issue is not addressed there and your configuration is set correctly
• Tested with the latest version to ensure the issue hasn't been fixed

How often does this bug occurs?

always

Expected behavior

esptool.py 5.3.1 flashes the identical image with compression at 460800 without errors:

Wrote 1343712 bytes (837302 compressed) at 0x00000000 in 6.6 seconds.
Hash of data verified.

Actual behavior (suspected bug)

writeFlash with compress: true fails deterministically at ~74–75 % of a ~1.3 MB image on an ESP32-S3 (native USB, USB-Serial/JTAG transport). The same image flashes fine with esptool.py (which compresses by default) and fine with esptool-js uncompressed.

Error logs or terminal output

Writing at 0x147424... (70%)
Writing at 0x14d56f... (71%)
Writing at 0x1537a0... (73%)
Writing at 0x15a12d... (75%)
Failed to write compressed data to flash after seq 42 failed with status 201,0


Identical failure point (`seq 42`) across repeated runs and across two different images of the same size, so it is content/sequence-deterministic, not marginal timing. Flash frequency ruled out (reproduced at 40m and 80m).

Steps to reproduce the behavior

• Chip: ESP32-S3 (QFN56) rev v0.2, 8 MB flash, USB-Serial/JTAG (native USB on macOS, Chrome, Web Serial)
• esptool-js 0.6.1 (bundle.js), baud 460800
• Image: merged ESP-IDF image, 1,343,696 bytes (bootloader + partition table + app), flash at 0x0

Project release version

0.6.1

System architecture

ARM 64-bit (Apple M1/M2, Raspberry Pi 4/5)

Operating system

MacOS + Chrome

Operating system version

• macOS Tahoe 26.6.2
• Chrome 151.0.7922.138

Shell

other (details in Additional context)

Additional context

Notes / hypotheses

• FLASH_WRITE_SIZE in esptool-js is 0x4000 for both plain and deflated writes. esptool.py uses a smaller compressed-block size in the deflate path; a stub buffer/boundary overflow would be consistent with a deterministic mid-image failure.
• Happy to test patches against the hardware here.