Regression: pump disconnects ~1s after auth completes, before any read succeeds (previously worked)

[eman]

Summary

The Python client used to work reliably against real hardware and now consistently fails: it connects and completes the authentication handshake, but the pump drops the BLE connection ~1 second later, before any read (get_mode(), telemetry, etc.) succeeds. Meanwhile, an ESP32/ESPHome device running the C++ port of this same protocol (eman/esphome-alpha-hwr) is currently working fine against hardware.

Environment

• Repo HEAD: 5c410f4 (Merge PR fix: authentication extension packet ordering and Bleak 3.x compatibility #25, fix/bleak3-compat)
• bleak 3.0.2 (matches pyproject.toml's bleak>=3.0.0 requirement)
• Python 3.14.6
• Editable install (pip show alpha-hwr confirms Editable project location points at this checkout)
• macOS (CoreBluetooth backend)

Symptom

1. connect() succeeds (BLE GATT connection + service/characteristic discovery).
2. authenticate() runs to completion and logs "Authentication handshake complete" (note: this log only means the packet burst was sent without a raised exception — the protocol doesn't wait for/verify a pump ACK, so "complete" is not proof the pump actually accepted the handshake).
3. ~1 second later, the BLE link drops. No read (control.get_mode(), telemetry.read_once(), etc.) has succeeded by this point.

What's been ruled out so far

• Not a BLE connection-slot conflict. The pump/ESP32 aren't fighting over a single connection slot — this was explicitly checked and is not the cause.
• Not a host-side Bluetooth/pairing change. Nothing changed in the host machine's Bluetooth settings, OS version, or bonding state since this last worked.
• Not the known "extension packets sent in wrong order" bug. This exact symptom ("disconnection ~1s after authentication") was previously root-caused and fixed in cd63399 ("fix: correct extension packet order to match connection.md protocol spec") and ee72412 ("fix: send extension packets sequentially in correct order"), both explicitly about issue Reading data fails on Alpha HWR #24. I confirmed the fix is present and active in the current tree — the editable install's AuthenticationHandler.EXTEND_1/EXTEND_2 decode to the corrected byte order (2705e7f805c14bc382 / 2705e7f80bc10fd0c3), and send_extension_packets() sends them sequentially with a 50ms gap, not concurrently. So whatever's happening now is not a recurrence of that specific bug, even though the symptom looks identical.

Other observations (not yet confirmed as relevant)

• The working tree currently has uncommitted local changes to src/alpha_hwr/core/transport.py, src/alpha_hwr/services/base.py, and src/alpha_hwr/services/control.py that add a send_wake_burst() retry mechanism and ConnectionError propagation for "pump goes silent/asleep after auth" style failures (matching the CHANGELOG's staged "Misleading error on mid-read disconnect" entry). These look like an in-progress fix for a related-but-distinct symptom (reads silently returning None/0 bytes) rather than this one (an actual link drop before any read completes), and haven't been fully tested. Flagging them here in case they're relevant, but they don't obviously explain a ~1s hard disconnect that happens before a read is even attempted.
• Stages 1 and 2 of the handshake (send_legacy_burst, send_class10_burst) still fire their repeated packets via asyncio.TaskGroup (concurrent tasks, historically the exact pattern that caused the extension-packet bug before it was serialized in ee72412). These haven't been changed and were presumably fine before, but are worth a second look given the symptom's similarity.
• The ESP32/C++ port (esphome-alpha-hwr) sends its equivalent bursts via a strictly serialized scheduler-callback chain (one packet, wait full delay, next packet — see auth.cpp), not concurrently. If timing jitter under load is a factor, this is a structural difference between the two implementations worth considering.

Next steps

Need an actual packet-level/debug-log capture of a repro to make further progress — specifically:

• bleak debug logs (logging.getLogger("bleak").setLevel(logging.DEBUG)) around the disconnect, to see whether the OS/CoreBluetooth reports a disconnect reason code.
• Whether the ~1s timing is exactly consistent across repeated attempts (suggesting a hard pump-side timeout waiting for something we're not sending) or variable (suggesting a timing/jitter issue in how we send the burst).

References

• Reading data fails on Alpha HWR #24 (original, resolved report of the same "~1s disconnect after auth" symptom, different root cause)
• cd63399, ee72412 (fixes for the previously-diagnosed cause, confirmed still in place)