[Bug]: console shows PATCH request with 409 Conflict result after cache clear (160001)

[lmeurs]

What happened?

The first time a page with our OneSignal implementation is loaded after clearing browser cache + cookies, the console shows a 409 Conflict error:

OneSignalApiBase.js:67 PATCH https://onesignal.com/api/v1/apps/800f295a-a6b2-49c9-9fb1-2555e1e8df91/users/by/onesignal_id/e99029ac-39b1-459c-9409-0b5c48cb78ab/identity 409

The URL shows the following message:

{"errors":[{"title":"No aliases found for oneSignalID e99029ac-39b1-459c-9409-0b5c48cb78ab"}]}

Our test OneSignal account only contains 4 subscriptions, none of them indeed has OneSignal ID e99029ac-39b1-459c-9409-0b5c48cb78ab. Sidenotes:

1. The error no longer occurs after reloading the page
2. The OneSignal ID changes each time when reproducing this

What browsers are you seeing the problem on?

Chrome (Chromium)

What operating system are you running?

W11

Steps to reproduce?

See description

What did you expect to happen?

No error

Relevant log output

No response

[jkasten2]

@lmeurs Thanks for reporting!

Looking to get a few more details to reproduce this issue:

1. Does the error only happen after calling OneSignal.User.addAlias?
2. Does it happen consistently?

2. The OneSignal ID changes each time when reproducing this

To answer your question on this, it is expected to get a new id each time the browser's cache and cookie / data is cleared. Since there is nothing in the browser left to know it is the same user.

[lmeurs]

Hi @jkasten2, this indeed seems to happen consistently.

The user is logged in successfully using OneSignal.login(123456). See screenshot: after the user logs in we do not query OneSignal users (on purpose at least), we only initialize the user by requesting an own API. That the 409 error is between two log messages about initializing the user is probably due to a promise being resolved asynchronously (see Notifications.prototype.apiRequestToInitNotificationUser in /js/notifications.js of the POC we shared with you).

You say:

[...] there is nothing in the browser left to know it is the same user

But we log the user in with an external ID, so the browser should be able to know the correct OneSignal user ID, but appears to lookup the user with a completely different OneSignal user ID which does not represent any user in our account. Heck, we currently only have 1 user in our test account with a different user ID. :-)

[lmeurs]

Hi @jkasten2, is there anything else we can do to help you investigate this issue?

[aleksi-magner]

Version: 160202

I also have the same error in this API PATCH https://onesignal.com/api/v1/apps/<app-id>/users/by/onesignal_id/<onesignal-id>/identity - I get a 409 status. But this happens after the logout() method and then login() have been called. And after clearing the cache too.

That is, the case is approximately as follows:

1. Init SDK
2. User login via login(<external_id_1>).
   At this step we create/update OneSignal ID, External ID, Subscription ID.
3. Log out of the application account, at the same time calling logout() without calling optOut().
   If you call optOut() before logout() there will be no error.
   At this step External ID is reset, generated new OneSignal ID, and Subscription ID remains the same.
4. Then log into the account under the new user, at the same time calling login(<external_id_2>).
   At this step, PATCH status 409 appears, because the request is sent with OneSignal ID from step 3. And only after the page is reloaded (not always the first time) the entry is updated again and with the correct OneSignal ID.

After the second user logs in, the first user’s entry is overwritten in the admin panel (dashboard), rather than a separate one being created.

Although sometimes Subscription ID disappears.

So far I have not found a way to work from several users from one device and so that notifications are available for each individually, and other users do not see neighboring ones