WSL: connect hangs after sidecar SIGTERM; queued connects never recover (must bypass with mpremote)

[bdbarnett]

Summary

After a failed or interrupted mpftp connect on WSL (COM port via the Windows sidecar), subsequent mpftp connect RPCs hang indefinitely. The only reliable recovery was to bypass the extension and talk to the board with direct python.exe -m mpremote connect COMxx ….

Environment

• Host: WSL2 (Ubuntu) + Windows COM ports
• mpftp extension: pydevices.mpftp-0.1.1 (Cursor)
• RPC: 127.0.0.1:7429
• Sidecar: Windows python.exe + sidecar.py
• Device: ESP32-S3 MicroPython on COM57

What happened

1. Normal connects/execs were working.
2. An exec raised a MicroPython AttributeError on the device (unrelated app bug).
3. A follow-up mpftp connect COM57 was started (to redeploy a fix).
4. That connect never completed. Parallel/queued connect RPCs also stalled.
5. Activity log shows the Windows sidecar exited (SIGTERM / later SIGKILL) while connect was in flight:
   • sidecar_exit → rpc_err connect: sidecar exited
   • sidecar restarted (sidecar_ready)
   • new connect RPCs were accepted but never returned rpc_ok connect
6. Meanwhile, direct mpremote worked immediately:

python.exe -m mpremote connect COM57 exec "print(123)"
# → 123

So the serial port and board were fine; the hung path was mpftp’s connect/sidecar session.

Expected

• After sidecar death or a killed CLI connect, the next mpftp connect should recover (or fail fast with a clear error).
• Queued/overlapping connects should not leave the session wedged until the Cursor window/extension is restarted.

Actual

• mpftp connect COM57 hung for 60s+ with no progress.
• mpftp status showed "connected": false.
• Activity log kept logging rpc connect with no matching success.
• Had to use direct mpremote for put/exec/soft-reset until the extension session was healthy again.

Suggested directions

• Fail fast (timeout) on connect if sidecar dies mid-flight; clear in-flight RPC state.
• On sidecar_exit, cancel pending connect waiters and surface sidecar exited to the CLI instead of hanging.
• Debounce/serialize connect: reject a second connect while one is outstanding.
• After sidecar restart, ensure COM handle ownership is released so the next connect can open the port (direct mpremote could, so this may be an RPC waiter leak rather than a stuck OS handle).

Worked-around-with

python.exe -m mpremote connect COM57 cp ./file.py :/lib/file.py
python.exe -m mpremote connect COM57 soft-reset
python.exe -m mpremote connect COM57 exec 'print("ok")'

Happy to attach a longer ~/.mpftp/activity.log excerpt if useful.