fix: crash about persistent websocket being started from background [WPB-6551] #2748
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.
Cherry pick from the original PR:
kalium
PR Submission Checklist for internal contributors
The PR Title
The PR Description
What's new in this PR?
Issues
Sometimes for results in .
Causes (Optional)
This exception means that was executed when it's not allowed to, there are multiple restrictions on when foreground service can be started - more here: https://developer.android.com/develop/background-work/services/foreground-services#background-start-restriction-exemptions
For us, we are allowed to start foreground service from Activity when the app is in the foreground and when the device is booted or app is updated (probably within 20 seconds) and we use for that. The problem is probably that we in a coroutine, so it's just left hanging and receiving new values even in the background.
Solutions
When is called, get the list of persistent websocket statuses only once to make sure that we open the service within the permitted time frame. This persistent websocket flag can be changed only in settings by the user when the app is in the foreground so no need to observe for changes in this receiver - if changed then the service will be started from .
The logic of deciding whether the service should be started or not is extracted to dedicated use case and tested.
Testing
Test Coverage (Optional)
How to Test
There's no specific reproduction path, from the logs it looks like it could happen when the app was updated in the background and the sync was started so that the user's values in database are updated and emits new list.
PR Post Submission Checklist for internal contributors (Optional)
PR Post Merge Checklist for internal contributors
References