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 so the SDK doesn’t pause the operation repo and 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_NORETRY) 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).

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

This aligns the behavior with expected semantics:

• INVALID → request is not valid and should not be retried indefinitely or cause global operation pausing.
  Avoids requiring uninstall/reinstall to recover after a restricted External ID attempt.

Testing

Unit testing

Updated unit coverage to verify ResponseStatusType.INVALID maps to ExecutionResult.FAIL_NORETRY (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

Threshold: 80%

Changed Files Coverage

• ❌ LoginUserOperationExecutor.kt: 0/168 lines (0.0%)
  • ⚠️ Below threshold: 168 uncovered lines

Overall Coverage

0/168 lines covered (0.0%)

❌ Coverage Check Failed

Files below 80% threshold:

• LoginUserOperationExecutor.kt: 0.0% (168 uncovered lines)

📥 View workflow run

[abdulraqeeb33]

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

[nan-li]

temp block