[fadi-george]

Description

One Line Summary

Calls before init, or after a failed init, log and do nothing instead of throwing: login, logout, updateUserJwt, the JWT listeners, and the User, Notifications, InAppMessages, Location and Session accessors.

Details

Motivation

A simpler alternative to the never-crash stack (#2800 to #2828) for the most common crash: calling login and friends before initWithContext, or after it failed. It reuses the existing init state and waitForInit instead of adding a new gate, deferred managers or a kill switch.

Scope

• Before init (NOT_STARTED) or after a failed init (FAILED), these calls log '<op>' ignored: ... with the init failure attached and return: login, logout, updateUserJwt, add/removeUserJwtInvalidatedListener, loginSuspend, logoutSuspend, updateUserJwtSuspend.
• The composite login still returns NOT_INITIALIZED, now through the same helper.
• The accessors (sync and suspend) log and return a no-op stand-in (UninitializedManagers.kt): getters return "", false or an empty map, everything else does nothing. For example OneSignal.User.onesignalId returns "", the same value the SDK already returns before the user is created.
• While init is IN_PROGRESS, calls still block until it finishes, same as today.
• Cancellation still propagates.

Not in this PR:

• A manager reference kept from before init (for example val user = OneSignal.User) stays the stand-in after init. Read the accessor again after init.
• Nullable initWithContext params, separate change.
• Calls dropped before init are not queued or replayed.

Testing

Unit testing

Updated the "throws before init" tests to assert the calls are ignored and the accessors return stand-ins, and added coverage for the FAILED state and the JWT listeners. Unit tests for core, notifications, in-app-messages and location, spotless, detekt and apiCheck pass. lintRelease reports 5 errors in files this PR does not touch (BackgroundManager, DatabaseCursor).

Manual testing

Not done yet.

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
• 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.
• I have reviewed this PR myself, ensuring it meets each checklist item

🤖 Generated with Claude Code

[github-actions]

📊 Diff Coverage Report

Diff Coverage Report (Changed Lines Only)

Gate: aggregate coverage on changed executable lines must be ≥ 80% (JaCoCo line data for lines touched in the diff).

Changed Files Coverage

• OneSignalImp.kt: 19/31 touched executable lines (61.3%) (44 touched lines in diff)
  • 12 uncovered touched lines in this file
• UninitializedManagers.kt: 9/56 touched executable lines (16.1%) (154 touched lines in diff)
  • 47 uncovered touched lines in this file

Overall (aggregate gate)

28/87 touched executable lines covered (32.2% — requires ≥ 80%)

Per-file detail (informational; gate is aggregate above):

• OneSignalImp.kt: 61.3% (12 uncovered touched lines)

• UninitializedManagers.kt: 16.1% (47 uncovered touched lines)

❌ Coverage Check Failed

Aggregate coverage on touched lines is 32.2% (minimum 80%).

📥 View workflow run