fix: login with the same externalId fails to update the subscription

[jinliu9508]

Description

One Line Summary

Fix issue where calling login with the same externalId as the previous app open fails to update the subscription in the backend.

Details

Motivation

Previously, when login was called using the same externalId as the previous app open, the SDK detected no change in the externalId and skipped creating a login request. Instead, it issued a refresh user request.

However, if the user’s external ID had been manually removed from the backend (for example, via the OneSignal Dashboard or calling Logout outside of SDK), this refresh request no longer linked the subscription with the intended externalId. The result was that the backend subscription remained unassociated with the external ID after login.

This change ensures that a login request is always created when login is called — even if the same externalId is passed again — so that the backend subscription is correctly updated and re-linked to that external ID. The subscription ID associated to the OneSignalID will still be reused.

Scope

• Affects user identity handling and external ID login flow.
• No changes to other SDK modules (notifications, outcomes, or in-app messaging).
• Maintains backward compatibility with existing login APIs.

Testing

Unit testing

Added a test unit to ensure a Login request is always created

Manual testing

Step to reproduce:

1. On a fresh install, call Login with an externalID right after initWithContext
2. Observe that the subscription is created with the externalID
3. Close app and remove the externalID through the dashboard
4. Open the app again, Login with the same externalID is called but the externalID is still missing for the subscription in backend.

After fix: The subscription has successfully restored the externalID after the second Login.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[nan-li]

Blocking while reviewing

[nan-li]

What do you mean by "if the user’s external ID had been manually removed from the backend" and "remove the externalID through the dashboard"?

[abdulraqeeb33]

Connected with @nan-li and @jinliu9508 , realized the current solution is not the ideal solution. We need to figure out a better solution for this issue.

[abdulraqeeb33]

This same behaviour exists in iOS, so we need to figure out what is it thats different we are doing.

is it possible that the login method is called so quickly and identityModelStore is not setup yet?