# Incident: HPT USB publish reported success before durable FAT commit

Status: complete
Result: resolved
Type: incident
Updated: 2026-07-29
Next Action: none; retain as historical evidence for the qualified publication lifecycle
Campaign: 003-complete-bounded-hpt-slow-export-firmware-ticket
Parent: work/wp/completed/wp-mitigate-and-diagnose-hpt-usb-publication-durability.md

## Impact

Controller B reported a successful customer export on replacement USB media,
but the Windows host found no final CSV, a zero-byte `HPTE.TMP`, and a
recoverable 128 KiB lost FAT chain. The operator cannot trust Success as proof
that removable-media publication is durable.

## Timeline

- Request 2 on the original stick failed at temporary-file deletion with USBX
  timeout `0x5C`; the HMI correctly displayed USB write error.
- Request 3 on replacement media returned success through write, close, two
  FileX flushes, rename, and HMI Success.
- Host inspection of the replacement found no CSV and one 128 KiB lost chain
  consistent with the `131064`-byte write.

## Cause

Confirmed implementation defect: USBX's FileX storage driver handles
`FX_DRIVER_FLUSH` as an unconditional no-op success. `fx_media_flush()` drains
FileX metadata and sector caches to USB WRITE commands but never issues SCSI
SYNCHRONIZE CACHE to the device. Current firmware also accepts final flush
success without reopening and verifying the renamed file.

Linux reported that the tested PNY device's write cache is disabled. After the
first mitigation, its two FAT copies differed and the exact 128 KiB allocation
remained unreferenced. Device caching is therefore not the primary cause;
inconsistent FileX/FAT metadata durability at removal remains the active cause
boundary.

## Recovery

Neither stick has been repaired. The original and replacement filesystem
states remain preserved for evidence. Controller B continues normal HPT
logging; the SD source is healthy and independent of this USB failure.

## Prevention

- Make USB `FX_DRIVER_FLUSH` issue SCSI SYNCHRONIZE CACHE and propagate failure.
- Reopen the renamed CSV and verify expected size and completion tail.
- Record synchronization and readback phases/status/metrics.
- Do not display Success until all durability gates pass.
- Document a removal-ready state and test host-visible contents after removal.

## Follow-Up

- Historical planning item: Implement and clean-build the driver and application changes.
- Historical planning item: Deploy the exact image to Controller B.
- Historical planning item: Test both preserved sticks without repair, then a known-clean stick if
  required.
- Historical planning item: Inspect the removed media on the host and reconcile controller telemetry
  with FAT/CSV evidence.
