Return to Loop in middle of Priming goes to Insert Cannula

[marionbarker]

Describe the bug
If the flow from Pair Pod to Priming to Continue screens is interrupted, for example by Loop crashing, and user resumes Loop and attempts to Finish Pairing, they are taken to the Insert Cannula screen even if the priming is still in progress.

To Reproduce
Steps to reproduce the behavior:

1. Use rPi DASH simulator
2. Pair new pod and then return to main loop screen while priming is in progress
   • Edited to add - this was from a quit Loop app and restart
   • Next comment has more steps with detailed behavior
3. Tap the Finish Pairing icon
4. User is taken to the Insert Cannula screen and if priming/initialization has not completed, they are given an error message that may lead them to think there is something wrong with the pod.

Graphic shows screen when priming is in progress (and pod is fine).

Solutions

1. We could add more words to the screen to indicate if pod is still priming (clicking) please wait - takes about a minute for priming to complete.
2. Modify the .deactivate actions in {DASH/Omnipod}UICoordinator.swift to modify state.

For example, if I add the line:

            self.pumpManager.podAttachmentConfirmed = false

to the DASH controller just before return hostedView in the case .deactivate section, then I return to the Attach Pod screen first (instead of the Insert Cannula screen. But it still doesn't check if pod is still priming.

Is there some other state parameter that could or should be set when deactivating?

[marionbarker]

Adding more ways in which I interrupted the Priming display on the Loop app using an rPi DASH simulator.

After hitting Pair Pod, no buttons are active until Priming starts.

1. Priming starts, you can press Deactivate in upper left:

   • On Deactivate screen, press deactivate and the next screen is Pair Pod
   • Tap pair pod and it continues with the current pod, showing priming in progress screen
     • If you wait long enough before tapping Pair Pod, the priming screen immediately shows a check mark
   • Rest of flow is as normal (and of course the starting pod was not actually deactivated)

2. Priming starts, you can press Deactivate in upper left:

   • On Deactivate screen, hit back and done and see main screen with Finish Pairing icon
   • Tap Finish Pairing - goes to Insert Cannula screen
     • If Priming has not had time to finish - get the not state ready message, retry works later
     • If it has been long enough, it works

3. Priming starts, quit out of Loop app

   • Restart Loop app
   • See main screen with Finish Pairing icon
   • Tap Finish Pairing - goes to Insert Cannula screen
     • If Priming has not had time to finish - get the not state ready message, retry works later
     • If it has been long enough, it works

Edited to add one more scenario:

4. Priming starts, you can press Deactivate in upper left:
   • On Deactivate screen, wait long enough for priming to have completed
   • Same behavior as Number 1 above.
   • Perhaps that Deactivate button should be made inactive as soon as Priming starts

[itsmojo]

The UICoordinator.determineInitialStep() was incorrectly skipping going to the Pair Pod view for an already paired pod that hasn't been confirmed to have completed its prime bolus. The pair pod view is really a pair and prime view and it must not be skipped unless podAttachmentConfirmed is true.

podAttachmentConfirmed is a persistent pumpManagerState variable which was incorectly never being reset to false for each new pod.

Loop should never allow the user to go Back to the previous view or to Cancel ot the HUD from the Pair Pod view once a pod has (internally been) paired (i.e., once the priming bolus has started). The current code to handle this was not working because the PairPodViewModel.podIsActivated var was always returned false instead of checking the actual pumpManager PodCommState.

These issues as well as a better user experience on an app restart during pod setup (no need to press or slide a button in the pair or insert cannula views if a bolus is still in progress or hasn't been seen as completed yet) are all fixed in the following PR's:

• Pod setup restart fixes and improvements (Loop issue #2117) OmniKit#27
• Pod setup restart fixes and improvements (Loop issue #2117) OmniBLE#113

[itsmojo]

Additional improvements so that the user shouldn't need to do a manual Retry after resuming a pod setup operation. Previously about 1 out of every 2 or 3 pod setup resumes in mid-operation would require a user to do a manual Retry after getting something like a one time Pod not connected or Empty Value error.

• Eliminate user retries on pod setup resumes (Loop issue #2117 follow up) OmniKit#28
• Eliminate user retries on pod setup resumes (Loop issue #2117 follow up) OmniBLE#114

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.

[marionbarker]

Fixed in dev. Leave open until released in main.