Store updated doses immediately before a pod fault is reported - #119
Open
itsmojo wants to merge 1 commit into
Open
Store updated doses immediately before a pod fault is reported#119itsmojo wants to merge 1 commit into
itsmojo wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
This PR is a follow up to OmnipodKit #99 as suggested in the Possible later change section. With this PR, all updated dose information will be stored immediately before the pod fault is reported to the controlling app. This means that the OS AID app will be able to have all the correct insulin delivery info for its IOB calculation immediately after the the pod fault is first seen by OmnipodKit regardless of which pod command the pod fault information is returned.
Previously in the various flavors of Omni PumpManagers (OmniKit/OmniBLE/OmnipodKit), the updated dosing information was only be stored after a get status was performed returning a pod fault which could potentially be a few minutes after a pod fault was first returned for some other pod command. A case of this was originally reported in Trio Issue 1236 for a cancel bolus command. OmnipodKit #99 made OmnipodKit work as well as OmniBLE for reporting the dosing information after a pod fault is seen during a cancel bolus command, but didn't fix the delayed dosing update in some cases. While the resulting behavior of potentially having to wait for the next get status call or the pod deactivation to have the updated IOB information displayed in the OS AID app is not a fatal flaw, it can cause user distress/confusion. This PR will alleviate this remaining misbehavior.
Description
The needed changes were not that large and are pretty isolated and so by inspection it is pretty clear this code will not change anything before the pod fault occurs and it only comes into effect the one time on the initial transition to a faulted state. There is only on place that handles the initial pod fault to update the dosing and sets the podState's fault member (PodCommsSession.handlePodFault()) and one place that handles updating the podState in the OmniPumpManagerState and notifying the delegate (the OS AID app) of this change (OmniPumpManager.setStateWithResult()) that needed changes so that the store() of the updated but still not finalized doses could be done at the needed time with the various locking and variable constraints.
Testing
The base for testing this code could be the post OmnipodKit #99 for the Bolus, inject Fault, Cancel Bolus case where the dosing info is not updated until the next update cycle. After applying this code from this PR, the dosing and IOB information should be updated immediately when the OS AID app displays the fault instead of having to wait for the next update or pod deactivation.