fix: SDK stuck in bad state when calling login with restricted external IDs

[jinliu9508]

Description

One Line Summary

Treat restricted/invalid External ID login responses as non-retryable failures and does not need further handling so the SDK doesn’t pause the operation repo to get stuck in a bad state.

Details

Motivation

We reproduced an issue where calling OneSignal.login() with a restricted / blocked External ID can leave the SDK in a “bad” state where subsequent operations stop working until reinstall. The root cause is that the network response is being mapped to FAIL_PAUSE_OPREPO, which pauses the operation repository and effectively prevents recovery.

This PR changes the execution mapping so invalid (restricted) responses are treated as a non-retryable failure (FAIL_INVALID_LOGIN) that don't retry rather than pausing the op repo. This allows the SDK to continue functioning and lets the app recover (e.g., by retrying with a different External ID or after logout).

• Why don't we map it to FAIL_NO_RETRY? Because when we get a FAIL_NO_RETRY, we still try to recover by creating the user. By mapping the response to FAIL_INVALID_LOGIN, we completely disregard the bad request that will surely be rejected.

Scope

• Affected: Login-related operations that receive an INVALID response status (e.g., restricted/blocked External IDs). OperationRepo execution handling for this response type.
• Not affected: Retryable / unauthorized handling (RETRYABLE, UNAUTHORIZED) and normal successful login flows. No public API behavior changes besides avoiding an unrecoverable stuck state.

OPTIONAL - Other

We are basically hitting this loop:

1. login(externalId) updates local identity state (externalId is set)
2. backend rejects it (400 “restricted”), but the op is treated as “pause and retry later”
3. user never gets created (onesignalId stays unset)
4. the “bad state recovery” sees externalId set + onesignalId unset and tries to “recover”
5. recovery replays the same login, which will always be rejected -> stuck

Testing

Unit testing

Updated unit coverage to verify ResponseStatusType.INVALID maps to ExecutionResult.FAIL_INVALID_LOGIN (and does not return FAIL_PAUSE_OPREPO).

Manual testing

Tested on emulator Pixel 7 API 33
Step to reproduce:

1. Install app
2. Call Login with external ID "1"
3. Observe that the SDK is now stuck in a bad state and unable to perform any operation until app is reinstall.

After fix: Now able to call Logout or Login with another valid external ID.

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 

[github-actions]

📊 Diff Coverage Report

Diff Coverage Report (Changed Lines Only)

Threshold: 80%

Changed Files Coverage

• ✅ IOperationExecutor.kt: 1/1 changed lines (100.0%) (3 changed lines)
• ❌ LoginUserOperationExecutor.kt: 0/1 changed lines (0.0%) (3 changed lines)
  • ⚠️ Below threshold: 1 uncovered changed lines

Overall Coverage (Changed Lines Only)

1/2 changed lines covered (50.0%)

❌ Coverage Check Failed

Files below 80% threshold:

• LoginUserOperationExecutor.kt: 0.0% (1 uncovered changed lines)

📥 View workflow run

[abdulraqeeb33]

looks fine to me. thank you for adding the unit tests

[nan-li]

temp block

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.