[Fix] Handle incorrect `404`, delay making requests to new IDs #1470

* This rule `opening_brace` declares opening braces should be on the same line as the declaration * However for multiline if / let statements, it makes it harder to read: if let blah = blah, let foo = blah.foo { // do something, less readable } if let blah = blah, let foo = blah.foo { // do something, more readable } * See linked PR for an upcoming option, so we can re-enable this rule

* This is a new behavior which waits a specific amount of time after something is created (such as a User or Subscription) before making a network call to get or update it. * The main motivation is that the OneSignal's server may return a 404 if you attempt to GET or PATCH on something that was just created. This is due fact that OneSignal's backend server replication sometimes has a delay under load. This may be considered a bug in the backend, but the SDK has a responsibility to handle this case as well. Additional Details: * User Manager owns an instance of OSNewRecordsState * Requests will check their records within the `prepareForExecution()` check

* Push subscription IDs and onesignal IDs can be added to the new records storage after they are created * Requests can be delayed by a specific “cool down” period plus a small buffer - they are flushed after a delay when they need to wait for the "cool down" period to access a user or subscription after its creation. * Anytime `prepareForExecution()` fails, the executor will put a delayed task to flush the requests again again after a specific delay. * In CreateUser, new IDs will only be added to the new records storage if the Creates were truly Creates, and not “faux” Creates meant to get an onesignal ID for a given external ID. This latter case happens after a 409 Identify conflict, meaning the user definitely exists and the Onesignal ID will not be new. * In IdentifyUser successful, the executor adds onesignal ID to new records again because an immediate fetch for hydration may not return the newly-applied external ID. We will encounter a problem with hydration in this case. * User fetch will always be called after a delay unless it is to refresh the user state on a new session. This is because a fetch that is not on a new session is always for getting user data after a create or identify. * Nits: Also moved some opening braces to new lines for improved readability of multi-line “if / let / guard” statements

* Executors init take in additional argument * A failing test needs more time to complete

* The canAccess method should really check a non-optional string * Adjust the use of this method at the calling site

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Fix] Handle incorrect `404`, delay making requests to new IDs #1470

[Fix] Handle incorrect `404`, delay making requests to new IDs #1470

Commits on Aug 16, 2024

[Fix] Handle incorrect 404, delay making requests to new IDs #1470

[Fix] Handle incorrect 404, delay making requests to new IDs #1470

Commits on Aug 16, 2024

[Fix] Handle incorrect `404`, delay making requests to new IDs #1470

[Fix] Handle incorrect `404`, delay making requests to new IDs #1470