Fix user executor's requests from being blocked#1398
Merged
Conversation
Add more verbose logging Make descriptions of objects clearer.
* This was a todo and after thinking about it and testing, I do think this is unexpected but OK. * Any remedy to this should not be happening right here anyway
* Context: The user executor stops executing requests from its queue once it hits a request that cannot be sent (yet) since these need to go in order and some requests may be waiting on information from the response to previous request. * When the user executor uncaches any requests, such requests can be: - Fetch Identity by Subscription - only requires an app_id to be sent - Create User - only requires app_id to be sent - Transfer Subscription - requires subscription_id to be sent - Identify User - requires the OSID of the anonymous user to be sent * Of those, we already drop transfer subscription requests who are missing the subscription_id and cannot be hooked up to a model to await the subscription _id. Otherwise, this request will forever block. * In this commit, we add the Identify User request as droppable if it is missing an OSID and it cannot be hooked up to an existing identity model to await the OSID. Otherwise, this request will forever block and remedy calls to `logout` or `login` will just sit in the queue. This scenario leads the SDK to be in a state of having an EUID but forever no OSID, which is needed to make server calls.
* The executors read from cache but did not re-persist the new data if some requests or deltas were removed
jkasten2
approved these changes
Apr 5, 2024
This was referenced Apr 5, 2024
Merged
This was referenced Apr 10, 2024
This was referenced Apr 10, 2024
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
2 participants
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.
Description
One Line Summary
Drop any cached Identify User requests that can never go through in order to prevent blocking of other pending requests and allow recovery.
Details
The logic of this PR is a small change in this commit: Drop insurmountable cached requests in the user executor
Motivation
An app developer through testing and usage of a debugging proxy ended up in a scenario where the SDK called
loginfrom an anonymous state, but is forever missing the onesignal ID to complete the Identify User call.logoutorlogin("another_user")don't work as they are added to the executor queue but the queue is still blocked by the first request.Scope
Testing
Unit testing
None
Manual testing
Physical iPhone 13 with iOS 17.4
I was not able to naturally reproduce this state by a combination:
I reproduced this state by:
login("a"), thenlogout(),login("a"),logout(),login("a")logout(),login("a"),logout(),login("a")are the pending requests"a"and correct data for user"a"Affected code checklist
Checklist
Overview
Testing
Final pass
This change is