[nan-li]

Description

One Line Summary

Remove the 5.3.0-beta pending-auth queues at start, cap cached values, make UserDefaults archiving exception-safe, and re-create a cached user whose Create User was lost. SDK-5314.

Details

Motivation

Devices upgrading from the 5.3.0-beta line carry five *_PENDING_QUEUE_KEY blobs that this branch never reads, and on affected devices those blobs and the regular queue keys are large. Archiving or writing an oversized queue is what crashes the beta today, and the UserDefaults helper here would crash the same way on an unarchivable or oversized value. A device whose only Create User sat in one of those blobs has an external_id and no onesignal_id, and nothing in the SDK would ever create it.

Scope

• OneSignalUserManagerImpl.start() removes the five beta pending keys before the executors read their caches. Their names return to OneSignalCommonDefines.h as OS_IV_BETA_*.
• Every cached queue read in the five executors and the operation repo passes a 1 MB cap, OS_USER_DEFAULTS_MAX_VALUE_BYTES, the same limit the write side applies. A larger blob is removed and logged, not decoded. The one-time transfer-subscription migration read is left as is.
• OneSignalUserDefaults catches exceptions from archiving and unarchiving instead of raising into the host app. A blob that is not archived data or cannot be decoded is logged and the default returned; a capped read also removes it, an uncapped read leaves it to the module that wrote it. A nil decode is treated like a missing key. A value that cannot be archived leaves the previous blob in place. A value whose archive is larger than 1 MB is not written and the key is removed: nothing the SDK caches is legitimately that large, and a previous blob left under the key would resend the Requests it held, which is the symptom this PR exists to stop. CFPreferences rejects values of 4 MB and more anyway.
• OSUserExecutor queues a Create User at start for a cached user that has no onesignal_id when nothing queued will supply one. The beta parked the only copy of that Request under a key this PR removes, and an oversized or undecodable queue loses it too; without this the device stays unreachable, since a login as the same user is a no-op. Under Identity Verification the Create User parks and asks the app for a token like any other; an anonymous cached user is left alone there, since it is never created. The recovery sees only the user start() loaded from the cache, captured when the executor is created, so a user that a login or a legacy-player migration sets up during the same start is not re-created.
• The beta's pending copies are dropped, not migrated. The beta also merged them into the regular queue keys, which this branch reads within the cap.
• No request payload changes. A dropped queue means its Requests are not sent.

Testing

Unit testing

Seven tests in OneSignalCoreTests cover a real archive over the cap, a blob within the cap, an unreadable blob, an unarchivable value leaving the cached value in place, a value over the limit taking the previous blob with it, and blobs that are not archived data or cannot be decoded being removed only by a capped read. One test in OneSignalUserTests seeds all five beta keys plus a real archive over the cap under the update key, written directly since the save path now refuses it, drives start(), and asserts the keys are gone and the queue is empty. Without the cap that archive decodes to strings, fails the cast and leaves the key as is, so the test fails. CachedUserWithoutAnIdTests covers the re-created Create User: an identified and an anonymous cached user with the requirement off, no duplicate when the Create User is still queued, the token ask and the signed Create User with the requirement on, and an anonymous cached user left alone under it. A fresh start still sends exactly one Create User and a legacy-player start queues none.

Manual testing

OneSignalCoreTests and OneSignalUserTests run on an iPhone 17 Pro simulator (iOS 26.5), and the full Reduced test plan ran on this branch merged with 5.8-main at 630b355, 597 tests with no failures. The dev app from the first revision of this branch installed over 5.3.0-beta-03 state with 8 parked Requests: the two beta keys present on that device removed at start, no crash, Requests held until a token arrives. The bug-bash run of 5 October reproduced the lost Create User on that upgrade path (scenario 12.3 in the test doc); the re-created Create User is covered by unit tests only so far. Not run on a device.

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

[fadi-george]

Potential issues:

• Possibly blocking: OSUserExecutor.swift:170, the 1 MB cap drops the whole request queue, including a pending Create User for the cached user. start() then loads that user from disk and never recreates it, so it never gets a onesignal_id and all its later updates stay stuck. Most likely on beta devices, since their parked logins were merged into this queue. Can you confirm or rule this out?
• Non-blocking: OneSignalUserDefaults.m:194, the write limit is 4 MB but the read limit is 1 MB. A queue between 1 and 4 MB saves fine, then gets silently dropped on the next launch. Probably worth fixing with the one above.
• Nit: OneSignalUserTests.swift:608, IdentityVerificationBetaCacheTests sits between the optedIn doc comment and RemoteDisableOptedInTests, so that comment now describes the wrong class.

[abdulraqeeb33]

Two places removeValueForKey deletes a blob the rest of this helper would have kept.

1. Unarchive @catch runs for every caller, including the identity model store. Gate that remove on maxBytes > 0.
2. The 4 MB write branch should return without removing, same as archive failure.

[nan-li]

Potential issues:

• Possibly blocking: OSUserExecutor.swift:170, the 1 MB cap drops the whole request queue, including a pending Create User for the cached user. start() then loads that user from disk and never recreates it, so it never gets a onesignal_id and all its later updates stay stuck. Most likely on beta devices, since their parked logins were merged into this queue. Can you confirm or rule this out?
• Non-blocking: OneSignalUserDefaults.m:194, the write limit is 4 MB but the read limit is 1 MB. A queue between 1 and 4 MB saves fine, then gets silently dropped on the next launch. Probably worth fixing with the one above.
• Nit: OneSignalUserTests.swift:608, IdentityVerificationBetaCacheTests sits between the optedIn doc comment and RemoteDisableOptedInTests, so that comment now describes the wrong class.

• Confirmed. The cap, an undecodable queue, and a beta device whose parked Create User sat only under a deleted pending key all leave a user with an external_id and no onesignal_id. I hit the last one on the simulator. start() now queues a Create User for a cached user with no onesignal_id when nothing queued will supply one, except an anonymous user under Identity Verification. Covered by CachedUserWithoutAnIdTests.
• Done, one 1 MB constant for both ends.
• Done, the class moved below RemoteDisableOptedInTests.

[abdulraqeeb33]

Read-path gate is done. The write wipe stays.

One remaining: recovery reads live _user on the executor queue. Path 2/3 can publish a new user before their append, so this block can enqueue a second Create User. Snapshot the Path 1 user in init.

[abdulraqeeb33]

Done in 5498904. Recovery now takes the Path 1 user captured in init. Nil means Path 2/3, and it returns before any async work.