[Bug]: iOS SDK does not auto-recreate Push Subscription when User has zero subscriptions after startNewSession self-heal check (fetchUser response omits subscriptions key) #1745

What happened?

The iOS SDK never recreates a new Push Subscription on subsequent app launches when a User's only Push Subscription is deleted server-side (e.g. via the OneSignal Dashboard) while the User itself is kept. The device is left permanently unable to receive push / IAM until the app is reinstalled.

We traced this to the onNewSession self-heal check in OSUserExecutor.executeFetchUserRequest:

if request.onNewSession,
   let subId = pushSubscriptionModel?.subscriptionId,
   let subscriptionObjects = self.parseSubscriptionObjectResponse(response) {
    // checks whether `subId` is present in `subscriptionObjects`; if not, calls createPushSubscriptionRequest()
}

parseSubscriptionObjectResponse is response?["subscriptions"] as? [[String: Any]]. Based on our trace, when the User has zero subscriptions, the fetchUser response omits the "subscriptions" key entirely (rather than returning an empty array). This makes the guard let subscriptionObjects = ... fail, so the whole self-heal block is skipped before it ever checks whether the locally cached subscriptionId still exists - createPushSubscriptionRequest() (i.e. POST /subscriptions) is never called.

For comparison, on Android (com.onesignal:core:5.1.35), SubscriptionOperationExecutor recreates the subscription reactively on a 404 from an update-subscription PATCH, regardless of the user's subscription count — so this class of issue does not reproduce there.

Steps to reproduce?

1. Log in a user with a stable external_id.
2. Confirm the User has exactly one Push Subscription.
3. From the Dashboard, delete that Subscription only (leave the User intact).
4. Relaunch the app (same install, same cached onesignal_id/external_id).

What did you expect to happen?

The SDK should detect that the locally cached subscriptionId no longer exists for this User and send a new create-subscription request, restoring push functionality - analogous to Android's behavior.

Actual Behavior

No create-subscription request is ever sent, on this or any subsequent app launch. The User remains at 0 subscriptions indefinitely. All subsequent requests scoped to the stale subscription (e.g. GET /apps/{app_id}/subscriptions/{subscription_id}/iams) fail with:

{
  "errors": [
    { "code": "subscription-0", "title": "Subscription not found" }
  ]
}

(HTTP 404)

Sanitized Trace (IDs redacted):

VERBOSE: OneSignal.User login called with externalId: <EXTERNAL_ID>
VERBOSE: OneSignalUserManager.createNewUser: not creating new user due to logging into the same user.)
...
VERBOSE: OneSignalUserManagerImpl starting new session
VERBOSE: OSUserExecutor.executePendingRequests called with queue [<OSRequestFetchUser with onesignal_id: <ONESIGNAL_ID>>]
...
VERBOSE: network response (OneSignalUser.OSRequestFetchUser) with URL https://api.onesignal.com/apps/<APP_ID>/users/by/onesignal_id/<ONESIGNAL_ID>: {
    httpStatusCode = 200;
    identity = {
        "external_id" = "<EXTERNAL_ID>";
        "onesignal_id" = "<ONESIGNAL_ID>";
    };
    properties = { ... };
    // NOTE: no "subscriptions" key present in the response at all
}
...
VERBOSE: network request (OSRequestGetInAppMessages) with URL https://api.onesignal.com/apps/<APP_ID>/subscriptions/<SUBSCRIPTION_ID>/iams
VERBOSE: network response (OneSignalUser.OSRequestGetInAppMessages) with URL https://api.onesignal.com/apps/<APP_ID>/subscriptions/<SUBSCRIPTION_ID>/iams: {
    errors = (
        { code = "subscription-0"; title = "Subscription not found"; }
    );
    httpStatusCode = 404;
}
VERBOSE: getInAppMessagesFromServer failure: <OneSignalClientError code: 404 ...>

No OSRequestCreateSubscription / POST /subscriptions request is ever logged after this point, on this session or later ones.

OneSignal iOS SDK version

OneSignalXCFramework: previous - 5.2.15, current (still reproduces) - 5.5.1

iOS version

26

Specific iOS version

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct