Defer forgetting sensor on suspected session end to avoid long reconnection outages - #62
Defer forgetting sensor on suspected session end to avoid long reconnection outages#62cheets wants to merge 1 commit into
Conversation
A remote disconnect before authentication completes is treated as a session end, immediately forgetting the sensor and scanning from scratch. The same disconnect signature occurs on transient BLE handshake failures (auth notification timeouts, encryption failures), where forgetting the tracked peripheral downgrades reconnection from an OS-level pending connect to a throttled background scan, causing 10-40 minute glucose outages. Field logs showed 118 suspected session ends in 7 days of which 1 was a real session end. Keep tracking the sensor on a suspected session end and defer the scan-for-new-sensor by a 15 minute wall-clock grace period, cancelled when any glucose or backfill message arrives. A real session end still switches sensors: the stopped sensor stays silent, the grace period expires, and the new sensor is discovered during its warmup. Immediate switch on sensorFailed/sessionEnded algorithm states is unchanged. Also add DI seams (central manager factory, injectable bluetooth manager, internal manager init) so G7CGMManager is unit-testable, plus a shared scheme with a test action.
| } | ||
|
|
||
| // A grace period is already running; keep its original deadline. | ||
| guard scheduled else { return } |
There was a problem hiding this comment.
Could we add a log here for future troubleshooting?
guard scheduled else { logDeviceCommunication("Suspected session end during active grace period; original deadline unchanged.", type: .connection) return }
|
This is a great contribution @cheets. I have been experiencing these same nuances myself with G7 so thank you for taking the time to look into this. One question I do have (which I think we can safely assume is very low probability), is how your code is handling a situation where at the 15 minute mark, you receive a glucose reading. As it stands, there is the possibility, however finite, that if a glucose reading comes in at 15 minutes, the work item has already been dispatched, and a new sensor scan is going to be triggered. Are we alright with acknowledging this as a low-probability edge case? |
2 participants
Problem
When a G7 disconnects before authentication completes,
G7SensorreportssuspectedEndOfSession=trueandG7CGMManagerimmediately forgets the sensor (sensorID = nil, peripheral forgotten) and starts scanning for a new one.The same disconnect signature is produced by ordinary transient BLE handshake failures — auth notification enable timeouts,
unknownCharacteristicduring incomplete service discovery,CBErrorencryption failures. In a week of device logs I collected, 118 suspected session ends fired, of which exactly 1 was a real session end. Each false positive forgets the tracked peripheral, which downgrades reconnection from an OS-level pending connect (instant wake when the sensor next transmits) to a throttled background scan plus full re-discovery. Result: recurring 10–40 minute glucose outages ("Searching for sensor"), during which Loop cannot dose. Worst observed: 45 minutes.Change
On a suspected session end, keep tracking the current sensor and defer
scanForNewSensor()by a 15-minute wall-clock grace period:sensorFailed/sessionEndedalgorithm states is unchanged — a sensor that announces its own session end still triggers an instant scan.The grace period uses a wall-clock deadline so device sleep cannot postpone detection of a genuinely ended session.
Also adds unit tests for the new behavior, with small DI seams to make
G7CGMManagertestable (central-manager factory to avoid the state-restoration exception in test bundles, injectableG7BluetoothManager, internal manager init), and a shared scheme with a test action.Field results
I have been running this for a month on my own Loop with no issues. From exported device logs:
A real sensor swap during the trial was handled by the unchanged
sessionEndedmessage path: old sensor forgotten immediately, new sensor discovered 3 minutes after activation, during warmup.Notes
This overlaps in intent with the
scanning-fixbranch ("Continue with sensor even after auth without control msg", "Use remote disconnect without auth/data as end-of-session detection again") — same underlying observation that auth-less remote disconnects are unreliable as a session-end signal. This change keeps the existing detection but makes acting on it tolerant to transient failures. Happy to adapt if maintainers prefer thescanning-fixdirection.