Fix: ANR on POST to Outcomes endpoint

[jinliu9508]

Description

One Line Summary

Prevent retrying 400 errors during cold start and clean up any previously saved bad records on device.

Details

Motivation

400 responses are client-side errors that will never succeed on retry. Currently, these can trigger retries during cold start, wasting resources and delaying initialization. In addition, if invalid/bad records were already persisted locally, the SDK would attempt to re-use them, leading to repeated failures.

Scope

• Affects cold-start retry handling logic and local record persistence.
• No impact to valid records or successful network requests.
• No API or behavior changes for SDK consumers beyond improved reliability and faster recovery from bad state.

Testing

Unit testing

Added/updated unit tests to cover:

• 400 errors are skipped from retry logic.
• Bad records persisted locally are correctly removed.

Manual testing

Environment: OneSignal example app, Pixel emulator API 33, debug build.

• Simulated cold start with server returning 400 → verified no retry attempted.
• Injected bad records into local storage → verified they are cleaned up on next init.

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]

What do you think about using our existing NetworkUtils infrastructure? To drop this for any non-RETRYABLE response

[abdulraqeeb33]

It seems like the backend is adding this to the header OneSignal-Retry-Limit

OneSignal-Android-SDK/OneSignalSDK/onesignal/core/src/main/java/com/onesignal/core/internal/http/impl/HttpClient.kt

Line 313 in 8116c60

private fun retryLimitFromResponse(con: HttpURLConnection): Int? {

I am wondering if its better to add some logic on the backend that if its a 400 (bad request - which is a client error) then set the retry limit to 0?
I can't think of any reason why a 400 should have a retry.

[jinliu9508]

What do you think about using our existing NetworkUtils infrastructure? To drop this for any non-RETRYABLE response

Good point, retrying is now only for retryable response. Omitting outcome event for any other error.

[nan-li]

For manual testing, did you compare with the current behavior?

Simulated cold start with server returning 400 → verified no retry attempted.

I'm seeing even without this PR, those 400 requests are not retried on new session or new cold start.