-
Notifications
You must be signed in to change notification settings - Fork 371
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
Recover null onesignal ID crashes for Operations #2157
Conversation
f18de03
to
8287a28
Compare
* When uncaching an Operation that is not login-related, check for the existence of onesignalId. * Note: The login-related Operations should still have onesignalId but they can be sent without it. It is also less likely for onesignalId to be null based on when these Operations are created. * This is to remedy a rare case that an Operation could be missing the onesignalId, which would continuously cause crashes when the Operation is processed. The particular reported Operation is an UpdateSubscriptionOperation.
8287a28
to
ba88ec2
Compare
* Switch Operation type in an existing test now that non-login Operations are expected to have OSID * The type of Operation used in the test is irrelevant
3fb7a38
to
9306f90
Compare
* Add new test file `OperationModelStoreTests` * Add test called "does not load invalid cached operations" that uncaches valid and invalid operations based on the new and existing checks in the OperationModelStore uncaching logic.
f9e998b
to
f7b0e5f
Compare
Thoughts on letting the first crash through when the Operation is first processed in the OpRepo? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code and the logic looks good to me and nice job on the testing unit!
I just want to confirm that the 'shouldRePersist' logic under ModelStore.load() will not persist the invalid operation in cases where the operation model store contains only invalid operation(s). If the bad data get to persist and we let the first crash through, I think the bad data won't get drop out of the persistent store and will cause another crash in next launch.
The bad operation won't be loaded and created so when the operations are all persisted again, it wont be there. |
Description
One Line Summary
Don't uncache invalid Operations that are missing onesignalId in order to prevent repetitive crashes when they go on to be processed.
Details
Motivation
Crash report showing high-volume repetitive crashes happening for a low volume of users.
onesignalId
isnull
for an UpdateSubscriptionOperationInvestigation
UpdateSubscriptionOperation
would get created without aonesignalId
initWithContext
finishes setting the local onesignalIdScope
Basically drop any Operation that is invalid and would not be sendable.
Testing
Unit testing
Manual testing
Device: Emulator Pixel 3 API 33
UpdateSubscriptionOperation
directlyAffected code checklist
Checklist
Overview
Testing
Final pass
This change is