Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent hang following restart if Pod Setup was interrupted #122

Merged
merged 1 commit into from
Apr 20, 2024

Conversation

marionbarker
Copy link
Collaborator

During testing, we discovered a rare case where Loop would hang following a quit/restart during the Pod Setup process.
The hang was noticed a few times out of dozens of tests - hard to reproduce with random swiping to quit Loop.
We identified how to reproduce the case and solved it with this PR.

Steps to reproduce the hang (with rPi and dev commit 130c6d5):

  1. Put a breakpoint in PodComms.swift at line 398
    • This pauses the Setup Process after keys are exchanged and 0x07 and 0x03 commands have processed
    • ^C out of rPi, quit and rebuild Loop
    • resume rPi and touch Finish Setup on Loop
    • Loop enters an infinite wait on the Pair Pod screen
  2. To break the infinite wait, build the fix_restart_hang branch instead of dev
    • resume rPi and touch Finish Setup on Loop
    • Loop proceeds nominally and primes rPi pod

Repeated this test with a DASH pod.
Same result - if paused and restarted app after the 0x03 command was issued, the infinite wait was observed with dev commit 130c6d5.
Rebuilt again with fix_restart_hang (commit e58045f), the pod continued to priming and to insertion.

@marionbarker marionbarker requested review from ps2 and itsmojo April 18, 2024 05:57
@marionbarker
Copy link
Collaborator Author

Improvements found with PR 113 and 114:

  • For all the cases for Loop v3.2.3 listed below, where a "good" pod had to be discarded, the improvement found in:
  • For the case listed below where the pod was still priming when Loop was restarted, the improvement found in PR 113/114 takes the user to the correct screen
  • This PR (122) addresses a very rare case in which the stored value of podState.setupProgress.isPaired is not saved as true but was instead reported as nil (only after quit/resume immediately after the 0x03 exchange)

Details for Loop v3.2.3 test:

  • Lines numbers for breakpoints are for commit f213607 of OmniBLE which is associated with release 3.2.3.
  • Test performed with rPi DASH simulator

Lost pod cases, saved by addition of PR 113/114:

When resume after quit / restart; Loop returns to insert cannula screen - cannot save pod, must Deactivate:

  • break at PodComms 398, after 0x07 and 0x03 have gone through
  • break at PodCommsSession 336, after 0x08
  • break at PodCommsSession 338, after 0x19

Could save pod, but messaging was wrong before PR 113/114

With this case, must just wait until priming is done but will be shown Insert Cannula screen even when priming has not finished.

  • break at PodCommsSession 358, after 0x1a starts priming

@marionbarker marionbarker merged commit e15b187 into dev Apr 20, 2024
@marionbarker marionbarker deleted the fix_restart_hang branch February 5, 2025 14:45
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.

2 participants