Replace Sensor" latched on a working Libre 3 Plus: stale event-log errorData 8 read as live sensor state #29

Summary

A FreeStyle Libre 3 Plus showed Replace Sensor / Sensor failed for 2 h 33 min (13:36 → 16:09 AEDT, 30 Oct 2026), while the sensor:

• reported patchState 4 (active) in every status packet,
• kept sending readings (117 dq=good readings after 13:36), and
• kept the host app (Trio) looping normally.

The state never cleared on its own; only pairing a new sensor cleared it. The user removed a working sensor at 5.6 of its 15 days.

Environment

Log and screenshots

📎 trio-libreloop-2026-10-30-redacted.zip (Trio Share logs export, 1.2 MB zipped, 54,815 lines, 30 Oct 00:00–19:03 AEDT)

15:57 Home	15:57 CGM page	16:09 Home
5.2 mmol/L, fresh, looping	Sensor failed, Bluetooth connected	4.7 mmol/L, looping, still flagged

To reproduce

Not deterministic: it needs the sensor to write an event-log entry with errorData = 8 while it is still active. In this log that happened during minute 8083 (≈13:22), right after a ~5 min app suspension, two notification-off writes from the silence watchdog, and the sensor dropping an authenticated connection (13:22:20).

An existing unit test on main already exercises this path: testReplacementRecordsTheSensorEndOnce feeds handlePatchStatus a frame with errorData = 8 and patchState = 4 (the helper's default, L182-L188) and asserts that the sensor end is recorded. sensorLifecycle is then .failed and stays there for repeated frames, whether or not actionable glucose keeps arriving. Suggested fix 1 would change that test's expectation.

Expected behavior

• A Sensor failed state needs corroboration that the sensor actually stopped: patchState leaving 4 (3/5/6/7/8), or glucose no longer arriving.
• An errorData code from an event-log entry while patchState == 4 raises at most a soft, retractable Check sensor notice, as e0282d0 already does for code 7.
• The same event entry doesn't re-alert when it repeats or after an app relaunch.

Sequence

Why it latches

1. Patch-status bytes 0–6 are the latest event-log entry.

2. RoundWhiteDiscKit treats that entry's errorData as a current condition. Libre3SensorAttention.init maps 8 → .replaceSensor regardless of patchState. The code describes the mapping as inferred (L46-L55), and neither DiaBLE nor Juggluco assigns meanings to errorData values.

3. LibreLoop's latch only re-evaluates on change. notifySensorAttentionIfNeeded returns early when attention == lastSensorAttention (L390) and persists sensorNeedsReplacement (L406-L414). LibreLoopSensorLifecycle.compute then returns .failed before rated wear. For the same sensor the only reset is a different attention value; otherwise only applyPairingOutcome clears it.

Was the sensor actually failing?

Not terminated, by every measure in the log: patchState 4 in all 70 packets after the event, 117 good readings after 13:36 with a smooth 5-minute history, last reading at 16:08:48, and no further event logged. The Bluetooth trouble was phone-side: SENSOR-B hit the same connect → no-stream pattern 16:30–17:13, about 20 minutes after pairing.

Impact

• In Trio (where this was observed): display plus one time-sensitive alert; dosing was unaffected. Trio stores hasValidSensorSession but never reads it (PluginSource.swift L244-L245), never reads isInoperable, and LibreLoop kept forwarding glucose. The real cost was a working sensor removed ~9 days early, plus ~70 min of warm-up without closed loop.
• In Loop: per e0282d0's description, a latched replace marks the CGM inoperable and stops Loop. On Loop next-dev, isInoperable puts a device issue on the loop status (Automation is unavailable), so a Loop user would be told to replace a sensor that is still delivering good readings. We haven't confirmed whether dosing actually stops: LoopDataManager.loop() doesn't read isInoperable or hasValidSensorSession.
• On main specifically: recordSensorStateIfChanged (from 04b0c03) also emits a .sensorIssue CgmEvent with isFatal: true and a .sensorEnd as soon as the flag latches. The working sensor's session would be recorded as ended at 13:36.

Suggested fix

1. Don't latch on errorData while patchState == 4. Downgrade to a retractable .checkSensor, as e0282d0 does for code 7 (widening the .checkSensor alert case at L429 so it still raises a notice), and keep the hard latch for non-active patch states. A sensor that really dies stops sending glucose, which already shows Signal loss after 6 min (L36) and stops the host looping on stale data.
2. Persist the handled event identity (lifeCount + index) so a repeated entry or an app relaunch doesn't re-alert. lastSensorAttention is in-memory only (LibreLoopCGMManager.swift L70). Optionally auto-clear once actionable readings newer than the event keep arriving.
3. (RoundWhiteDiscKit, optional) Expose the entry's age (currentLifeCount − lifeCount) and don't derive sensorAttention from errorData alone when patchState is active.

Related problems found along the way

• discardSensor resets lastSensorAttention but not sensorNeedsReplacement / sensorEndedNormally, and applyNFCResponse doesn't clear them either. So the new sensor shows Sensor failed from NFC scan until the pairing outcome (16:09:30 → 16:10:37 in this log, lines 47682 and 47930).
• The silence watchdog only checks cancellation at the top of its loop, so a finished monitor's in-flight tick sent a patch-status read (13:22:00) and a glucose notify-off (13:22:05, line 38975) onto the new connection, 15 s before the sensor dropped it. Possibly what provoked the event; not proven.
• The patch-status log line omits errorData, eventData, index and the disconnect-reason bytes. 04b0c03's .sensorIssue metadata now records errorData and patchState. eventData, index and the disconnect reasons only appear in the in-memory developer read inspector (L466-L475; last 300 reads, never persisted). They aren't logged or exported, so an entry like the one at minute 8083 can't be identified afterwards.

Additional context

• Precedent: e0282d0 (15 Jul) fixed the same false latch for code 7 and noted "Terminal replace (code 8, terminated) is unchanged." The only earlier field evidence for code 8 in this repo's history (16d74de, 1 Aug) came from a sensor shutting down after a clean end of wear.
• Open questions: what does errorData = 8 mean inside an event-log entry? Has anyone else seen errorData 8 with patchState 4 on a Libre 3 / 3 Plus, and what happened next?

Generated by Claude Code