Skip to content

Thread bolusReference through bolus delivery - #101

Closed
bjorkert wants to merge 2 commits into
loopandlearn:mainfrom
bjorkert:feature/bolus-reference
Closed

Thread bolusReference through bolus delivery#101
bjorkert wants to merge 2 commits into
loopandlearn:mainfrom
bjorkert:feature/bolus-reference

Conversation

@bjorkert

@bjorkert bjorkert commented Jul 1, 2026

Copy link
Copy Markdown
Member

Carries the bolusReference from enactBolus through UnfinalizedDose and PendingCommand and stamps it on the reported DoseEntry, so it survives an app restart while a bolus is in progress. Stored as a uuid string in the pod raw state.

Part of the bolus origin work: LoopKit/LoopKit#594 and nightscout/Trio#1252.

bjorkert added 2 commits July 1, 2026 11:48
Persist and echo the caller-supplied bolus reference via UnfinalizedDose and
PendingCommand, so it survives an app restart while delivery is in progress and
is stamped on the reported DoseEntry for both certain and uncertain delivery.
Match the LoopKit change: thread UUID instead of String, serialized as
uuidString in the rawValue round-trips.
@bjorkert

bjorkert commented Jul 1, 2026

Copy link
Copy Markdown
Member Author

Superseded by the dev-targeted PR above — same change rebased onto dev so Loop and Trio can share one OmnipodKit commit.

@bjorkert bjorkert closed this Jul 1, 2026
jeremybarnum pushed a commit to jeremybarnum/OmnipodKit that referenced this pull request Aug 19, 2026
…cted

Field 2026-08-19 12:56:53.974: timedConnect and adopt-retry both issued connect()
for the same pod in the SAME MILLISECOND, CoreBluetooth answered CBError 11, and a
single connect 0.75s later succeeded against an unchanged system.

The ledger cleared the two competing explanations in the same session. ORPHANED=1
stood across connects that SUCCEEDED, so a leaked intent does not hold a slot --
which kills the recreateCentral leak theory this instrumentation was built to test.
And the G7 had disconnected 2.3s before the refusal, so it was not holding the link
either. What was left was our own duplicate.

noteConnectIssued now returns a verdict and callers skip connect() when one is
already in flight. Suppressions are COUNTED, not silent: if suppressed=N climbs
while reclaims still fail, the duplicate was not the disease and the next suspect
is watchOS releasing a slot lazily (2.3s too soon, 3.0s enough).

Guards .connecting only. Connecting an already-.connected peripheral makes
CoreBluetooth re-deliver didConnect immediately and some state machine may lean on
that; this file compiles into the PHONE as well as the watch, so suppressing it
would risk wedging the phone's pod link to fix a watch symptom.

freshConnect passes force: its whole purpose is cancel-then-reconnect.

G7SensorKit learned this as the loopandlearn#101 churn fix; the pod path never got it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant