Skip to content

fix: [SDK-5537] log handled failures and setup mistakes below ERROR - #1778

Open
nan-li wants to merge 2 commits into
mainfrom
nan/sdk-5537
Open

nan-li wants to merge 2 commits into
mainfrom
nan/sdk-5537

Conversation

@nan-li

@nan-li nan-li commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

Description

One Line Summary

Log handled failures and setup mistakes below ERROR, so ERROR means an SDK fault.

Details

Motivation

Remote logging exports every line at or above the level the server sets. iOS logged ERROR for cases the SDK already handles, such as a 404 on fetch user or a denied location prompt, and that volume from 5.6.0+ installs trips alerts. Android made the same change in OneSignal-Android-SDK#2531.

Scope

  • WARN for setup mistakes, API misuse, and work the SDK drops. APNs registration errors, badge count and open-Settings errors, and a push subscription deleted on the server also log WARN.
  • INFO for failures the SDK handles or retries. DEBUG for housekeeping.
  • User executors log request failures through one helper, at INFO when the status is retryable and WARN otherwise. Create User logs ERROR only when the failure pauses the Operation Repo until the next session, and INFO otherwise.
  • ERROR stays for cache decode failures, the SDK's own JSON parsing, requests that cannot be built, Identity Verification refusals, and guards marked as never expected to fire. The invalid app ID stays FATAL, because without one the SDK never fetches params and remote logging never starts.
  • Two messages change. The privacy consent guard in OneSignalClient names the request class instead of printing a bare %@. The LiveActivities check at init logs its own INFO line, apart from the warning when the API is called without the module.
  • No public API changes.

Testing

Unit testing

No new tests. No existing test asserts the level of a changed line.

Manual testing

I ran the User, OSCore, Core and InAppMessages test bundles from the Reduced plan on an iPhone 17 Pro simulator with iOS 26.5.

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

Remote logging exports every line at or above the server-set level, and iOS
still used levels chosen for the Xcode console. This pass applies the rule from
SDK-3661: ERROR and FATAL mean the SDK did something wrong or hit a state it
cannot recover from. Anything the SDK handles, retries, or that the app
developer has to fix is WARN or below.

Request failures in the User executors go through a shared helper: INFO when
the response is retryable, WARN when the executor drops or holds the request.
Create User keeps ERROR on the branch that pauses the Operation Repo until the
next session, and logs INFO when it retries or holds for a token.

Setup mistakes stay visible at the default console level as WARN: missing
optional modules when their API is called, the missing location usage
description, the missing push capability, the simulator, API calls before
init, and invalid input to public APIs. Handled runtime conditions are INFO:
location denied, in-app message fetch, impression and WebView errors, receive
receipt and session outcome failures that retry, and the LiveActivities module
check at init, which now has its own message so it does not group with the
API-call warning. Housekeeping lines go to DEBUG.

The consent guard in OneSignalClient now formats the request class into its
message instead of printing a bare %@.

Kept at ERROR: cache decode failures, the SDK's own JSON parsing, requests
that cannot be built, Identity Verification refusals, and the "should never
happen" guards. The invalid app ID FATAL stays: a native app with a bad app ID
never fetches params, so remote logging never starts and nothing is exported.
Drop the note above the Create User ERROR branch. The comment below it
already says the pause lasts until a new session.

Cut the logRequestFailure doc to the caller rule its body cannot show.
@nan-li
nan-li marked this pull request as ready for review October 22, 2026 00:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant