restart-esp-usb reports success for a device that came back in an error state

[bdbarnett]

After a restart the script looks the device up again and logs what it found, then exits 0 whatever that was. The installed log from 2026-09-21 has the case:

pnputil /restart-device ok: ... Device restarted successfully.
back as "USB Composite Device" status=Error
--- restart-esp-usb done ---

LastTaskResult was 0 and the board had no COM port. That run was the old script against a node it had itself left disabled, and #33 now enables a disabled node first, so this exact path is closed. The shape is still there for any other reason a node comes back not OK: the caller reads 0 and believes the board is reachable.

What it should do: when the same instance id is present after the restart and its status is not OK, log the Problem code and exit with a code of its own (6 is free), and have mpftp usb-restart say so. A node that is gone afterwards stays a success, because that is a board re-enumerating in download mode.

The test doubles in cli/tests/esp_usb_doubles.ps1 can play this: a scenario where the node reads Error after /restart-device.

It waits because changing the installed script costs the owner another elevated install, and nothing depends on it today.

[bdbarnett]

Fixed in d6b83b6 (straight to main).

restart-esp-usb.ps1 now treats "same instance id, still present, status not OK" as a failure: it logs Windows' Problem code and exits 6. A node that is gone afterwards is still a success, as you asked — that is a board re-enumerating into download mode. mpftp usb-restart --instance also exits non-zero now instead of printing "ok": false and returning 0, and _EXIT_HINTS[6] says what to do about it.

esp_usb_doubles.ps1 gained the scenario you suggested plus its control:

• error-after — pnputil restarts it, the node comes back CM_PROB_FAILED_START
• gone-after — pnputil restarts it, the id is not there afterwards

Run here, PYTHONPATH=cli/src python3 -m unittest discover -s cli/tests, 332 tests, OK; the file itself is 42 tests (was 39).

Shown failing, against a copy of the script with the new block deleted (MPFTP_ESP_USB_SCRIPT):

test_a_node_that_comes_back_not_ok_is_not_a_success ... FAIL   AssertionError: 0 != 6
test_the_problem_code_is_logged_so_the_wall_can_be_named ... FAIL
test_a_node_that_is_gone_afterwards_is_still_a_success ... ok

and the transcript the faulted copy left is the 2026-09-21 log, line for line:

pnputil /restart-device ok: Device restarted successfully.
back as "a test double" status=Error
--- restart-esp-usb done ---

The gone-after leg staying green is the point of it being there — if it ever goes red beside the other two, the check has started firing on the normal case and every flash reports failure.

One thing left, and it is yours: the copy under C:\Program Files\mpftp still has the old behaviour. It changes only when tools/windows/install-restart-esp-usb-task.ps1 is run again from an administrator PowerShell.