Skip to content

Bug Tracker

Last updated: 2026-02-11 21:34:43 UTC

Status: Active
Owner: BionicLoop engineering

Use this file for high-priority defects that affect safety, runtime reliability, or clinical confidence.

Tracked Bugs

Bug ID Title Severity Status
BUG-001 Meal announce incorrectly blocked after relaunch when loop cadence had missed steps High Closed
BUG-002 Home No Pod state shown during expected transient DASH reconnect cycle Medium Open

BUG-001

  • ID: BUG-001
  • Title: Meal announce incorrectly blocked after relaunch when loop cadence had missed steps
  • Severity: High
  • Area: Runtime availability / Meal announce

Description

If the app is terminated, one or more scheduled loop steps are missed, and the app is later relaunched, meal announcement can be reported as unavailable even when the session is active and the pump is otherwise ready.

Why this matters

This can block timely meal input and reduce trust in loop behavior after normal app lifecycle interruptions.

Observed behavior (prior to fix)

  • Meal announce is blocked in relaunch scenarios where cadence continuity had a gap.
  • User receives a generic unavailable state instead of a state aligned to real-time borrow/pump readiness.

Expected behavior

  • Meal announce availability should be computed from current runtime conditions (armed state, borrow window, pump readiness), not blocked only because prior scheduled steps were missed while the app was not running.

Acceptance criteria

  • Relaunch after missed steps does not by itself block meal announce.
  • Availability reason reflects true blocking cause (pump delivering, cannot borrow, signal loss, etc.).
  • Automated tests cover relaunch + missed-step scenarios for meal availability.
  • Closure evidence includes integration/runtime tests; UI automation is supplementary and not the sole closure artifact for this bug.

Current implementation map

  1. User taps Let's Eat on Home.
  2. Home calls loopRuntime.mealAnnouncementAvailability().
  3. If unavailable, Home shows a reason modal and does not present meal composer.
  4. If available, Home presents meal composer (meal time + carb-size selection + slide to deliver).
  5. On deliver, Home calls loopRuntime.announceMeal(...).
  6. Runtime calls coordinator announceMeal(...), which runs executeDoWork(cause: .mealAnnounce, mealAnnouncement: ...).
  7. Coordinator validates pump readiness first (must not be delivering and must not be unknown).
  8. If request is pre-due (expectedStep < nextStep), coordinator applies borrow-window checks:
  9. 0 < timeUntilNextStep <= 2 * stepInterval.
  10. On success, executes at stepToExecute = nextStep and consumes borrowed slot.
  11. If request is due/missed (expectedStep >= nextStep), coordinator executes at stepToExecute = expectedStep.
  12. If eligibility checks fail, coordinator returns skipReason = cannotBorrow.

Key runtime gating and timing rules

  • Step interval: 300s (5 min), lead time: 27s.
  • Availability computes:
  • nextStep = lastExecutedStep + 1
  • nextStepExecutionTime = firstSuccessfulStepAt + nextStep * 300s
  • earliestBorrowTime = nextStepExecutionTime - 600s
  • dueBoundary = nextStepExecutionTime - 27s
  • Availability window is:
  • now >= earliestBorrowTime and now < dueBoundary.
  • If now < earliestBorrowTime: reason tooEarly.
  • If now >= dueBoundary and now < nextStepExecutionTime: reason tooLate and wait-until shown.
  • If now >= nextStepExecutionTime: availability is allowed to execute meal on current due step.

BUG-001 relaunch block path (historical, pre-fix)

  1. App is terminated for long enough that one or more scheduled slots are missed.
  2. On relaunch, runtime keeps persisted firstSuccessfulStepAt and lastExecutedStep.
  3. Runtime intentionally suppresses an immediate doWork from cached CGM timestamp and waits for next new CGM timestamp.
  4. During that wait, nextStepExecutionTime is in the past relative to wall-clock.
  5. mealAnnouncementAvailability() returns tooLate because now >= dueBoundary.
  6. Since no catch-up step has executed yet, lastExecutedStep does not advance, so meal remains blocked.
  7. Meal announce becomes potentially available only after a fresh CGM-triggered doWork executes and advances runtime state.

Reviewer checklist for fix design

  • Confirm whether meal flow should be blocked while awaiting first post-relaunch CGM-triggered catch-up step.
  • If not, decide whether to:
  • run a catch-up doWork on-demand before meal availability decision, or
  • allow meal announce to drive catch-up + meal execution in one path.
  • Keep borrow semantics aligned with Marjorie behavior (borrow future slot, consume slot, max two-slot borrow).

Current implementation decision (provisional)

  • Implemented behavior:
  • In pre-due window, meal announce still uses borrow gating.
  • If the next scheduled slot is already due/missed, meal announce executes on current due step (expectedStep) instead of being blocked as tooLate.
  • tooLate retry time now points to the immediate next due-step boundary instead of adding a fixed extra 5-minute wait.
  • This behavior is marked for explicit team review to confirm intended clinical workflow and parity expectations.

Verification evidence to date

  • Core integration-style test passing:
  • BionicLoopCoreTests.testMealAnnounceExecutesCurrentDueStepWhenScheduledStepIsAlreadyDue
  • App-level availability/message tests passing:
  • BionicLoopTests.testMealAnnouncementPresentationLoopOff
  • BionicLoopTests.testMealAnnouncementPresentationSignalLoss
  • BionicLoopTests.testMealAnnouncementPresentationTooEarlyTimeMessage
  • BionicLoopTests.testMealPumpUnavailableReasonMapping

Remaining closure evidence

  • Optional UI automation for presentation path (sheet shown/dismissed) may be added, but does not replace runtime/integration evidence for this defect.

Closure evidence (2026-02-11 real-device run)

  • Test context:
  • App killed at 08:47 local, relaunched at 08:49 local.
  • Expected scheduled step around 08:48 was missed while app was terminated.
  • Observed:
  • Meal composer opened successfully after relaunch (not blocked by missed step).
  • Meal selection + delivery path executed.
  • Runtime log confirms due/missed step execution path:
    • BionicLoop: doWork cause=mealAnnounce expected=455 executed=455 applied=true skip=none
  • Recent step timeline confirms delivered meal-associated step:
    • Step 455 Dose 1.25U at approximately 08:49:55.
  • Evidence artifacts:
  • Home + meal flow screenshots captured for compose, selected meal, post-delivery state, and recent steps.
  • Console session captured from relaunch through meal execution and pump status progression.
  • Storage path:
    • Docs/Quality/Evidence/STR-BUG-001/2026-02-11-relaunch-meal/

BUG-002

  • ID: BUG-002
  • Title: Home No Pod state shown during expected transient DASH reconnect cycle
  • Severity: Medium
  • Area: Home status UX / Pump connectivity projection

Description

The Home view can switch to No Pod immediately on pod disconnect notifications, even when this disconnect is part of the normal ~3-minute DASH disconnect/reconnect cycle and reconnect succeeds quickly.

Why this matters

This creates false alarm UX and unnecessary user concern despite normal pump behavior.

Current behavior

  • Home state reflects disconnect immediately.
  • Short transient reconnect cycles can flash No Pod before reconnect completes.

Expected behavior

  • Apply a 5-second debounce before presenting No Pod on Home.
  • If reconnect completes within debounce, do not show No Pod.
  • Show No Pod only when disconnect persists beyond debounce or confirmed status remains unavailable.

Acceptance criteria

  • Disconnect + reconnect within 5 seconds does not show No Pod.
  • Disconnect persisting beyond 5 seconds shows No Pod.
  • Tests cover both debounce paths.