Repository navigation
Auto bolus is giving a different amount than it shows in the UI #2196
Description
Describe the bug
In the UI it shows one amount but the auto bolus keep going
Attach an Issue Report
See reports attached.
To Reproduce
Steps to reproduce the behavior:
Unknown how to reproduce
Expected behavior
Give only the amount the UI shows it will give
Screenshots
See attached.
Loop Report 2024-07-21 000507-0400.md
Export-20240721T040614Z.zip
Phone
- Ihpone 14 pro
- OS Version: 17.4.1
Loop Version
- Loop 3.4
- Repo: github.com/DavidRYL/LoopFollow
CGM - Device: Dexcom G7
- Manager app: Dexcom App
Pump
Omnipod Dash
Activity
itsmojo commentedon Jul 22, 2024
See latest comments on LoopKit 2195. OmniBLE PR #125 and OmniKit PR #36 might eliminate the possibility of this happening any more. But if this is not sufficient, Loop should also check bolusState to not start a bolus when one is currently in progress.
marionbarker commentedon Aug 12, 2024
Got another report of this today. (I'll add notes in a bit.)
The proposed fix is in OmniXXX.
@ps2: Can we get a patch added to Loop 3.4.1 to include the updated OmniXXX code?
marionbarker commentedon Aug 12, 2024
I got a Loop report from Facebook user Stefano Anghera who experienced this display bug.
The csv file from that report is attached.
The user reported:
"this morning the event timestamp is about at 09:24 after the manual bolus of 6 units at 09:17, it starts an automatic bolus but i stopped it after 0,75 units (the automatic bolus showed was about over 5 units)."
This is an excerpt from my email to him.
It is a display problem only. The amount indicated for the total bolus on the HUD is left over from the previous manual bolus.
The logs are in UTC, so 9:24 your time (local) is 7:24 in the logs.
I see:
I understand why you canceled the automatic bolus - I would have done the same. But the pod delivery would have stopped on its own.
csv file of pod messages from the Loop Report:
podState_Stefano_Anghera_20240812_1214_1.csv
DavidRYL commentedon Aug 12, 2024
I got this again last week! I didn't catch the logs in time. I had a 200% override turned on and basal lock turned on at 200. I stopped it here as I had no idea when it would stop. From what I checked afterward, it intended to bolus me a total of 1.8.
live4sw commentedon Sep 30, 2024
I had this issue or a similar one happen this morning. No overrides running, had added my breakfast carbs, saw a bolus begin that got to "Bolused 0.4 of 0.15 U" and then I stopped it.
I then noticed it was listed as an "Interrupted Bolus: 0.4 of 0.9 U" (9/30/24 7:24AM bolus), so that reassures me it wasn't going to go indefinitely and was just a display issue, but wanted to bring it to your attention.
Issue report attached (just redacted the username in the file path) which I generated right after it happened.
Loop Report 2024-09-30 07_25_21-04_00.md
itsmojo commentedon Oct 2, 2024
Thank you for the detailed observations and capturing the log right after it happened @live4sw. Here’s a summary of the basic pod commands at the end of the comms log (N.B., all times UTC).
This problem description says that the HUD showed “0.4 of 0.15 U” and then the bolus was cancelled after this botched bolus display was noted. But from the comms log, the bolus that was canceled was actually a 0.9U auto bolus that was started at 11:24:03. And this was confirmed by the eventual logging which showed “Interrupted Bolus: 0.4 of 0.9 U” (9/30/24 7:24M bolus). Thus this appears to be HUD bolus display problem before and totally independent of the cancel bolus operation that was performed. In the incorrect bolus display immediately before the cancel, the bolus amount delivered was apparently correct (i.e., the “0.4U”), but the displayed “of 0.15 U” was incorrect and probably from a much earlier bolus. There was a 0.15U auto bolus at 11:04:02 which was the 2nd bolus before and 20 minutes prior to the 0.9U bolus at 11:24:03 that was actually in progress. Interestingly enough, the 3rd previous bolus a full 40 minutes prior to the interrupted 0.9U bolus was also for 0.15U (perhaps this could be a contributing factor). This bogus display doesn’t appear to be a problem resulting from a side effect of any pod comms errors as were no unacknowledged messages on 09-30.
In summary, this HUD UI bolus display problem seems to be totally independent any cancel bolus handling or comms errors and could easily be independent of the underlying pump manager type altogether. Someone needs to look for something in the higher level bolus HUD UI code that might result in an “of amount” value being displayed from a previous bolus in some cases.
elnjensen commentedon Oct 2, 2024
All the reports I've seen of this display bug have been for Omnipod, but FYI that I observed this recently with my Medtronic 522 pump as well. Unfortunately I don't have logs to share.
Running Loop dev, code is basically in line with the current release.
Edit to add: this supports @itsmojo's recent comment that this behavior may be independent of the pump manager.
itsmojo commentedon Oct 4, 2024
Going back and looking at the Loop Report from @DavidRYL on July 21st, here’s a summary of the boluses from the comms log around the time of the bogus HUD bolus display (N.B., all times UTC) with some additional notes.
In this case, the bolus “of 0.30U” HUD display is apparently based on the 4th previous bolus nearly 48 minutes prior the actual 1.10U bolus which had 1.05U delivered. From comparing these incorrect bolus HUD cases from @DavidRYL & @live4sw, it appears that having 2 consecutive boluses of the same amount is not a factor, that auto bolus vs manual boluses is not a [direct] factor, and that the earlier bolus apparently being incorrect used for “of X.XXU” display is not a consistent # of boluses before (4 versus 2 or 3) or time before (47m53s vs 20m1s or 40m2s) the actual on-going bolus.
itsmojo commentedon Oct 14, 2024
It appears that if Loop is put in the background while displaying an in-progress bolus and then put into the foreground later in the middle of some other bolus, Loop will incorrectly try to reuse the BolusProgressTableViewCell from the original bolus and its totalUnits value for the actual in-progress bolus. In the reported errors, this is was getting noticed by users when the actual in-progress bolus size when the app is put in the foreground was greater than the total size of the previous bolus when the app was put in the background, but other confused HUD bolus will happen anytime the app / the phone is closed in the middle of one bolus and then resumed / opened in the middle of another bolus.
To reproduce this in Xcode, add a test in BolusProgressTableViewCell:updateProgress after the progress let variable is set. If progress is greater than 1.0, then print statement of the interesting variables and set an Xcode breakpoint there. You will need the Loop app to auto bolus with the app in the background, I used an old Eros pod on a test iPhone with a simulated CGM with high values. It’s also helpful to enable Extended Confidence Reminders and make sure the pod isn’t Silenced to make it easier to detect an auto bolus with the phone closed. Then add a lot of carbs which should suggest a large bolus value. Use a smaller bolus value of something like 0.3U. Then start the bolus and wait for the HUD display to show “Bolused X of 0.3U” and then immediately close the phone before the bolus finishes. Then wait until your pod beeps &/or is ticking for the next auto bolus, open your phone and the Loop app after a second. Loop will incorrect use the in-progress bolus info from the smaller original 0.3U bolus but should hit the breakpoint instead of the progress > 1 if statement when the auto bolus amount is larger than the original bolus (in my example 0.3U). The display will stop showing something like “Bolused 0.10 of 0.30 U” but you should (eventually) hit the breakpoint set inside of the added progress > 1 if statement.
The code in BolusProgressTableViewCell and part of StatusTableViewController handling this stuff is still using UIKit code. I am unfamiliar with the UIKit (and SwiftUI) rules & conventions for apps going in to the background and foreground with their UI state, but it seems like this UI code isn’t correctly handling a bolus ending while the app is no longer in the foreground and/or it needs to re-verify its in-progress bolus display state when the app is brought back into the foreground at it potentially might be in the middle of a different bolus.
marionbarker commentedon Nov 15, 2024
@itsmojo found a method to stimulate this error when using an rPi DASH simulator. Reporting this method so tests can be applied to a proposed fix, when that is presented for formal review.
For the example described above, the bolus display continued until 1.55 U was delivered with final message of 1.55 U of 0.5 U shown on the main screen.
To test successive times, put the app into the background before the bolus progress bar completes.
marionbarker commentedon Mar 19, 2025
The solution is known. Just need to get it added to Loop.
A customization is provided in the interim.
marionbarker commentedon Apr 24, 2025
Closed with Loop 3.6.0