Repository navigation
fix(cbio): give the harness a scan pass that bounds and closes itself - #205
shroominic wants to merge 1 commit into
Conversation
The authenticated harness scanned only with an FF30 service filter and trusted two signals it does not own: it awaited `startScan` before arming any bound, and it subscribed to `scanResults` after the radio was already running. When the plugin left `startScan` pending, the acquisition loop never advanced, and the run burned the full 8-minute test timeout without reaching a verdict. The app driver does not do either of those. Its filtered pass is followed by one unfiltered retry, because this sensor's advertisement does not always carry the service UUID in the field Android filters on, and a foreign advertiser is still never surfaced: every result has to classify as an FF30 candidate first. The harness now uses that proven shape. A pass subscribes to `onScanResults` before starting the radio, owns a hard deadline, ends on either the plugin's stopped signal or that deadline, and stops the scanner on the way out without waiting on a plugin future that a stopped radio no longer needs. An empty filtered pass is followed by one unfiltered pass, and the run now reports which pass found the target. Refs #201
|
Re-ran the device session from the branch tip (
One observation handed to the decode lane as #207: every raw glucose field in the |
|
Not absorbed by the GS1 consolidation (#209, feature/cbio-gs1). Left open on purpose: the self-owned bounded scan pass (unfiltered fallback plus its own deadline) is not in the consolidated harness. Owner: device-evidence harness lane. |
|
Carried into #209 (head The bounded Closing as carried. Carrying PR: #209. |
Closes #201. Base: #204.
The authenticated harness acquired its target with a single filtered scan, and it trusted two signals it does not own: it awaited
startScan(...)before arming any bound, and it subscribed toscanResultsafter the radio was already running. Whenflutter_blue_plusleavesstartScanpending, the acquisition loop never advances and the run reaches neither a target nor itsaborted_no_targetverdict — the unbounded wait behind the two runs in #199 that burned the full 8-minute test timeout with no artifact.The app driver and app transport already solve both halves of this on the same phone:
packages/cgm_cbio/lib/src/cbio_driver.dartruns a filtered pass and then one unfiltered retry, because this sensor's advertisement does not always carry the service UUID in the field Android filters on. A foreign advertiser is still never surfaced: every result must classify as an FF30 candidate.gs1-session-20260918T051210-...jsonrecords the filtered-only failure (aborted_no_targetafter 90 s).packages/cgm_ble_flutter/lib/src/flutter_blue_plus_transport.dartsubscribes toonScanResultsbefore starting, arms its own deadline, and closes the caller's stream before plugin cleanup that can block.The harness now uses that shape. A pass subscribes before starting the radio, owns a hard deadline, ends on either the plugin's stopped signal or that deadline, stops the scanner on the way out without waiting on a plugin future whose radio already stopped, and records a
scan_failedreason when start fails. An empty filtered pass is followed by one unfiltered pass, and the run reportsCBIO-A scan-source=filtered|unfilteredso the next reviewer can see which path found the sensor.No assertion is relaxed, and no part of the safety envelope changes: the allowed-write set, the closed error taxonomy, and every
CbioSessionEvidenceinvariant are untouched.Device evidence with #202 and #204 in place: