fix: [SDK-4388] subscription state permanently stuck at "Never Subscribed" when login() is called before requestPermission() by abdulraqeeb33 · Pull Request #2627 · OneSignal/OneSignal-Android-SDK

abdulraqeeb33 · 2026-04-27T18:35:08Z

Summary

Fixes SDK-4388. On a fresh install, when OneSignal.login(externalId) is called after initWithContext but before requestPermission(), the server-side subscription gets permanently stuck at enabled:false, notification_types:0 ("Never Subscribed / Permission Not Granted") even though the device is fully subscribed locally (optedIn == true).

Cherry-picked from @fadii925's fadi/sdk-4388-... branch (which is based on 5.7-main) onto main. Authorship preserved.

Repro (from the ticket)

Fresh install → initWithContext runs, SDK POSTs /apps/.../users → server responds 201 with a server-assigned subscriptionId.
FCM returns a push token → SDK enqueues update-subscription(NO_PERMISSION).
App calls OneSignal.login(externalId) → SDK runs createAndSwitchToNewUser(), which enqueues create-subscription reusing the server-assigned subscriptionId + login-user with existingOnesignalId.
App calls requestPermission() → user grants → SDK enqueues update-subscription(SUBSCRIBED).
Op queue flushes:
- update-subscription(NO_PERMISSION) → PATCH /subscriptions/{id} → 200. Server: enabled:false, notification_types:0.
- login-user → PATCH .../identity → SUCCESS_STARTING_ONLY. Remaining ops translated from local user onto server user.
- create-subscription + update-subscription(SUBSCRIBED) batched into one POST .../subscriptions with { id:"<server-uuid>", enabled:true, notification_types:1 } → 200 {} (no-op, subscription already exists). The enabled:true is silently discarded.
No further PATCH is issued → server stays at enabled:false, notification_types:0 permanently.

Root cause

SubscriptionOperationExecutor.createSubscription was always issuing a POST /subscriptions for CreateSubscriptionOperation, regardless of whether the carried subscriptionId was local or already a server-assigned UUID. When the id is already known to the backend, POST is silently treated as a no-op and the merged enabled/address/status payload is dropped.

This happens specifically on login() because UserSwitcher.createAndSwitchToNewUser reuses the existing push subscription's id under the new local user, and SubscriptionModelStoreListener.getAddOperation mechanically converts the resulting model add into a CreateSubscriptionOperation carrying that real id. Combined with GroupComparisonType.ALTER grouping it with the follow-up update-subscription(SUBSCRIBED), the executor ends up POSTing a doomed batch.

Fix

In SubscriptionOperationExecutor.execute(), branch on IDManager.isLocalId(startingOp.subscriptionId) for CreateSubscriptionOperation:

Local id (genuinely new subscription): keep existing createSubscription path → POST /subscriptions.
Non-local id (subscription already on backend): route through new updateExistingSubscriptionFromCreate helper which collapses the merged final state (enabled/address/status from the last UpdateSubscriptionOperation if present, otherwise from the create op) into an UpdateSubscriptionOperation and dispatches via updateSubscription → PATCH /subscriptions/{id}.

This implements option (a) from the ticket. Option (b) (drop the create op) was rejected because it would no-op when there's no follow-up UpdateSubscriptionOperation in the batch.

The delete short-circuit (if (operations.any { it is DeleteSubscriptionOperation }) return SUCCESS) is preserved in the new helper.

Customer impact

App ID: e198f6f8-f233-4073-8380-4a3c79ae64e7
Affected SDK: Android Native 5.7.7 and earlier (likely all 5.x versions with this code path)
Customer workaround: call requestPermission() before login(), or REST-API correct stuck subscriptions via PATCH /apps/{app_id}/subscriptions/{subscription_id} with {"subscription": {"notification_types": 1}}.

Test plan

New unit test "create subscription with non-local id PATCHes instead of POSTing when grouped with update" reproduces the SDK-4388 scenario (Create(NO_PERMISSION) + Update(SUBSCRIBED) with non-local id) and asserts a single PATCH with enabled:true, notificationTypes=SUBSCRIBED, zero POSTs.
Existing test "create subscription includes the subscription ID if non-local" rewritten to assert PATCH (the previous "POST with existing id" behavior is no longer correct).
Pre-existing test coverage for create-subscription with local id, transfer, delete, and update paths preserved unchanged.
CI: ./gradlew :OneSignal:core:testReleaseUnitTest green.
Manual: repro the ticket flow on a fresh install (initWithContext → login → requestPermission) and verify the server-side subscription ends at enabled:true, notification_types:1.

Followups (not in this PR)

The root modeling issue is that UserSwitcher.createAndSwitchToNewUser re-attaches an existing server-assigned subscription model under a new local user, which the model-store listener interprets as a brand-new subscription needing creation. A follow-up should consider either:

Emitting a TransferSubscriptionOperation (or no-op) instead of CreateSubscriptionOperation in the listener when IDManager.isLocalId(model.id) is false, or
Handling the re-attach with NO_PROPOGATE in createAndSwitchToNewUser and explicitly enqueuing a transfer op.

There is also a sibling code path in LoginUserOperationExecutor.createSubscriptionsFromOperation(CreateSubscriptionOperation, ...) that does the same if (!isLocalId) operation.subscriptionId else null trick when sending to /users (the non-SUCCESS_STARTING_ONLY path), and is not addressed here.

Backport

This fix should also land on 5.7-main for the next 5.7.x patch release. @fadii925's original branch is already based on 5.7-main and can be PR'd there directly: https://github.com/OneSignal/OneSignal-Android-SDK/tree/fadi/sdk-4388-android-sdk-subscription-state-permanently-stuck-at-never

Copilot

Pull request overview

Fixes SDK-4388 where calling OneSignal.login() before requestPermission() could leave the backend push subscription permanently stuck in a “Never Subscribed / Permission Not Granted” state by ensuring “create with non-local subscriptionId” is executed as an update (PATCH) rather than a create (POST).

Changes:

Route CreateSubscriptionOperation with a non-local subscriptionId through a new “update existing subscription” path (PATCH) instead of POSTing /subscriptions.
Stop including subscriptionId in the create-subscription request payload (always POST with id = null) for the local-id create path.
Update/extend unit tests to assert PATCH behavior for non-local create, including the grouped create+update repro.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
`OneSignalSDK/onesignal/core/src/main/java/com/onesignal/user/internal/operations/impl/executors/SubscriptionOperationExecutor.kt`	Adds branching + helper to PATCH when `CreateSubscriptionOperation` carries a non-local subscription id; ensures POST create path doesn’t send an id.
`OneSignalSDK/onesignal/core/src/test/java/com/onesignal/user/internal/operations/SubscriptionOperationExecutorTests.kt`	Updates existing test expectations and adds a repro test for grouped create+update to ensure a single PATCH and no POST.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

nan-li

await review

Adds three tests covering branches in `updateExistingSubscriptionFromCreate` that the SDK-4388 fix introduced but didn't fully exercise: 1. Create + Delete with non-local id is a successful no-op (locks in the delete short-circuit so a future refactor can't accidentally route to PATCH and resurrect a deleted subscription). 2. Network-retryable backend errors on the PATCH path propagate as FAIL_RETRY with retryAfterSeconds (matches the local-id Create behavior and ensures errors aren't swallowed). 3. Multiple batched updates with a non-local-id Create collapse into a single PATCH carrying the *last* update's values (locks in last-wins semantics; mirrors the existing local-id POST test). These complement the two existing non-local-id tests and bring coverage for the new path to parity with the local-id Create path. Made-with: Cursor

When updateSubscription gets a 404 outside the missing-retry window we re-enqueue a CreateSubscriptionOperation so OperationRepo can rebuild the subscription. Reusing the original non-local subscriptionId on that recovery op routes it back through execute() -> updateExistingSubscriptionFromCreate -> PATCH, which immediately 404s again and re-enqueues another non-local Create, looping indefinitely without backoff (observed at ~4-6 PATCH/sec until the backend rate-limits with 429s). Generate a fresh local id via IDManager.createLocalId() for the recovery Create. A local id forces execute() down the POST/rebuild-user path in createSubscription, which is the one that can actually re-create the subscription on the backend.

Locks in the recovery shape after an update-subscription 404 outside the missing-retry window: one CreateSubscriptionOperation in the response operations, with a fresh local subscriptionId (not the original non-local one) so the next execute() dispatches it through the POST / rebuild-user path instead of looping back into PATCH -> 404. All other fields (appId, onesignalId, externalId, type, enabled, address, status) must propagate from the failed update so the recovered subscription matches the desired state.

github-actions · 2026-05-11T23:51:10Z

📊 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

SubscriptionOperationExecutor.kt: 0/27 touched executable lines (0.0%) (58 touched lines in diff)
- 27 uncovered touched lines in this file

Overall (aggregate gate)

0/27 touched executable lines covered (0.0% — requires ≥ 80%)

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

SubscriptionOperationExecutor.kt: 0.0% (27 uncovered touched lines)

❌ Coverage Check Failed

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

📥 View workflow run

Strip "SDK-4388" prefixes from comments in SubscriptionOperationExecutor and its test class. The descriptive context that followed the ticket id already explains the why; the ticket id itself is noise for future maintainers and is preserved in git history / commit messages.

…l id When PATCH /subscriptions/{id} returns 404 outside the missing-retry window, updateSubscription() already mints a fresh local id for the recovery CreateSubscriptionOperation to break the PATCH -> 404 loop. However, the cached SubscriptionModel and ConfigModel.pushSubscriptionId still hold the stale non-local id, so the rebuild-user path (LoginUserOperationExecutor.getRebuildOperationsIfCurrentUser) emits a second CreateSubscriptionOperation carrying that stale id. Both Creates end up in the POST /users payload and the backend creates two subscription rows for the same device. Rewrite the cached SubscriptionModel id and pushSubscriptionId to the new local id (HYDRATE so no listener reacts) before returning the recovery op. The rebuild path then emits a Create with the same local id, dedupe collapses the two ops, and POST /users carries a single subscription as it does on the un-fixed path.

… on PATCH 404 Extend the PATCH-404 recovery regression test to assert that the cached SubscriptionModel id and ConfigModel.pushSubscriptionId are rewritten to the same fresh local id used on the recovery CreateSubscriptionOperation. Without this realignment the rebuild-user path would emit a duplicate Create with the stale non-local id and LoginUserOperationExecutor's POST /users would create two subscription rows on the backend for the same device.

Copilot AI review requested due to automatic review settings April 27, 2026 18:35

Copilot started reviewing on behalf of abdulraqeeb33 April 27, 2026 18:35 View session

Copilot AI reviewed Apr 27, 2026

View reviewed changes

Comment thread .../java/com/onesignal/user/internal/operations/impl/executors/SubscriptionOperationExecutor.kt

fadi-george approved these changes Apr 27, 2026

View reviewed changes

claude Bot reviewed Apr 27, 2026

View reviewed changes

Comment thread .../java/com/onesignal/user/internal/operations/impl/executors/SubscriptionOperationExecutor.kt

nan-li requested changes Apr 27, 2026

View reviewed changes

nan-li reviewed Apr 27, 2026

View reviewed changes

Comment thread .../java/com/onesignal/user/internal/operations/impl/executors/SubscriptionOperationExecutor.kt

sherwinski mentioned this pull request May 6, 2026

fix: [SDK-4474] self-heal SDK-4388-stuck push subscriptions on session start #2636

Merged

18 tasks

fadi-george and others added 5 commits May 11, 2026 16:30

fix(subscriptions): patch existing subscription instead of post

3f235e2

refactor(subscriptions): move non-local id check earlier

780c4f7

sherwinski force-pushed the ar/sdk-4388-android-sdk-subscription-state-permanently-stuck-at-never branch from 24a3623 to 37a793c Compare May 11, 2026 23:40

sherwinski force-pushed the ar/sdk-4388-android-sdk-subscription-state-permanently-stuck-at-never branch from 720e7ea to 3117820 Compare May 12, 2026 16:57

sherwinski added 2 commits May 12, 2026 16:28

sherwinski requested a review from nan-li May 13, 2026 21:00

nan-li approved these changes May 15, 2026

View reviewed changes

sherwinski merged commit e3d72a5 into main May 15, 2026
4 of 5 checks passed

sherwinski deleted the ar/sdk-4388-android-sdk-subscription-state-permanently-stuck-at-never branch May 15, 2026 21:54

github-actions Bot mentioned this pull request May 15, 2026

build: Release v5.9.2 #2649

Merged

This was referenced May 15, 2026

chore: Release 5.3.10 OneSignal/OneSignal-Cordova-SDK#1178

Open

chore: Release 1.0.5 OneSignal/OneSignal-Capacitor-SDK#24

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: [SDK-4388] subscription state permanently stuck at "Never Subscribed" when login() is called before requestPermission()#2627

fix: [SDK-4388] subscription state permanently stuck at "Never Subscribed" when login() is called before requestPermission()#2627
sherwinski merged 8 commits into
mainfrom
ar/sdk-4388-android-sdk-subscription-state-permanently-stuck-at-never

abdulraqeeb33 commented Apr 27, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

nan-li left a comment

Uh oh!

Uh oh!

github-actions Bot commented May 11, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

abdulraqeeb33 commented Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Repro (from the ticket)

Root cause

Fix

Customer impact

Test plan

Followups (not in this PR)

Backport

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

nan-li left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions Bot commented May 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📊 Diff Coverage Report

Diff Coverage Report (Changed Lines Only)

Changed Files Coverage

Overall (aggregate gate)

❌ Coverage Check Failed

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

abdulraqeeb33 commented Apr 27, 2026 •

edited

Loading

github-actions Bot commented May 11, 2026 •

edited

Loading