feat: identity verification 5.8 by nan-li · Pull Request #2599 · OneSignal/OneSignal-Android-SDK

nan-li · 2026-03-30T09:21:48Z

Description

One Line Summary

Add Identity Verification (JWT-based) support to the Android SDK, gating API operations behind server-issued JWTs when enabled.

Details

Motivation

Identity Verification allows app developers to authenticate users with JWTs before the SDK sends operations to the OneSignal backend. This prevents unauthorized API calls by requiring a valid JWT for all user-scoped operations when the feature is enabled server-side via the jwt_required remote param.

Scope

Public API additions:

OneSignal.login(externalId, jwtBearerToken) — accepts an optional JWT on login
OneSignal.updateUserJwt(externalId, token) — supply a fresh JWT when the current one expires
OneSignal.addUserJwtInvalidatedListener(listener) / removeUserJwtInvalidatedListener(listener) — get notified when a JWT is invalidated (e.g. 401 from backend) so the app can provide a new one
IUserJwtInvalidatedListener / UserJwtInvalidatedEvent — listener interface and event class

Internal changes:

JwtTokenStore — persistent store mapping externalId → JWT, backed by SharedPreferences
IdentityVerificationService — reacts to the jwt_required remote param arriving via config HYDRATE; purges anonymous operations when IV is enabled; wires JWT invalidation callbacks
OperationRepo — gates operation execution on valid JWT when IV is enabled (hasValidJwtIfRequired); handles FAIL_UNAUTHORIZED by invalidating the JWT, re-queuing operations, and notifying the developer; stamps externalId synchronously at enqueue time to avoid race conditions
LogoutHelper — when IV is enabled, disables the push subscription internally and suppresses the backend login operation (the device-scoped user is local-only)
ConfigModelStoreListener / ParamsBackendService — reads jwt_required from remote params, defaults to false when absent
HTTP layer — attaches Authorization: Bearer <jwt> header to requests when IV is enabled
In-App Messaging — uses alias-based fetch endpoint and includes JWT in IAM backend calls
Operation executors — propagate externalId to result operations and attach JWT to backend requests

What is NOT affected:

Apps without Identity Verification enabled behave exactly as before — jwt_required defaults to false and no JWT gating occurs
Notification display, open handling, push processing, and confirm deliveries are unchanged

Testing

Unit testing

WIP Adding more testing

OperationRepoTests — added tests for FAIL_UNAUTHORIZED handling (identified user fires handler + retries; anonymous user drops operations), and synchronous externalId stamping before async dispatch
LoginUserOperationExecutorTests — updated for identity verification parameters
LogoutHelperTests — covers IV-enabled logout flow
LoginHelperTests — covers IV-enabled login flow with JWT

Manual testing

Tested with the demo app on an Android emulator (Pixel 7, API 35):

Login with valid JWT → operations execute normally
Login with expired JWT → 401 triggers IUserJwtInvalidatedListener, call updateUserJwt → operations resume
Logout with IV enabled → push subscription disabled, new anonymous user created locally
App without IV enabled → SDK operates normally, no regression

Affected code checklist

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

...DK/onesignal/core/src/main/java/com/onesignal/core/internal/operations/impl/OperationRepo.kt

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/user/internal/LogoutHelper.kt

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/user/internal/identity/JwtTokenStore.kt

...DK/onesignal/core/src/main/java/com/onesignal/core/internal/operations/impl/OperationRepo.kt

nan-li · 2026-03-31T07:26:01Z

@claude re-review

claude · 2026-03-31T07:26:17Z

Claude finished @nan-li's task in 3m 55s —— View job

Re-review: feat/identity_verification_5.8

Read current state of files related to previous review findings
Verify fixes for the 4 critical issues flagged
Look for any remaining or new issues
Post updated review

All four critical issues flagged in the previous review have been addressed. Here's a status breakdown:

Previously Critical — Now Fixed ✅

1. Runtime 401 not firing IUserJwtInvalidatedListener (OperationRepo.kt:292-297)

Fixed correctly. OperationRepo now holds a _jwtInvalidatedHandler: ((String) -> Unit)? that is set in IdentityVerificationService.start():

_operationRepo.setJwtInvalidatedHandler { externalId ->
    _userManager.fireJwtInvalidated(externalId)
}

And in the FAIL_UNAUTHORIZED branch, _jwtInvalidatedHandler?.invoke(externalId) is called after _jwtTokenStore.invalidateJwt(externalId). The queue correctly re-enqueues the operations, and the developer receives the callback to provide a fresh JWT. When updateUserJwt is called, forceExecuteOperations() wakes the queue — the full round trip is wired.

2. Logout race condition — UpdateSubscriptionOperation stamped with null externalId (OperationRepo.kt:165-168)

Fixed correctly. stampExternalId(operation) is now called synchronously in enqueue() before scope.launch { internalEnqueue(...) }. Since SubscriptionModelStoreListener.getUpdateOperation() fires synchronously when isDisabledInternally = true is set — and createAndSwitchToNewUser() has not yet run at that point — _identityModelStore.model.externalId is still the old user's ID when it's captured.

3. JwtTokenStore.ensureLoaded() throws uncaught JSONException (JwtTokenStore.kt:32-42)

Fixed correctly. The JSON parsing is wrapped in try { } catch (e: Exception) and isLoaded = true is placed unconditionally at the end of ensureLoaded(). Corrupted SharedPreferences data is now logged and discarded gracefully instead of causing an infinite throw loop.

4. useIdentityVerification stays null for non-IV apps, permanently blocking the queue (ParamsBackendService.kt:87)

Fixed correctly. The field now defaults to false when jwt_required is absent from the backend response:

useIdentityVerification = responseJson.safeBool("jwt_required") ?: false

Non-IV apps get false after HYDRATE, getNextOps() proceeds, and IdentityVerificationService.onModelReplaced() still calls forceExecuteOperations() to wake the queue.

Remaining Observations (non-blocking)

A. _jwtInvalidatedHandler is not @Volatile (OperationRepo.kt:47)

private var _jwtInvalidatedHandler: ((String) -> Unit)? = null

This field is written from IdentityVerificationService.start() (likely the main thread) and read from executeOperations() running on OSOperationRepoScope. In practice this is safe because start() runs before any operations execute, but the JMM doesn't guarantee visibility without @Volatile or a synchronisation point. Worth annotating for correctness. Fix this →

B. Expired JWT at logout time blocks the unsubscribe operation (LogoutHelper.kt)

When IV=true and a 401 has already invalidated the JWT before the user calls logout(), the UpdateSubscriptionOperation (to disable the push subscription) gets a null result from _jwtTokenStore.getJwt(externalId) and is permanently held by hasValidJwtIfRequired. The developer would need to call updateUserJwt with a fresh token to unblock it — but if they're logging out, they likely won't. The backend push subscription stays enabled for the logged-out user until the next cold start (when pruneToExternalIds cleans up the orphaned operation).

This is an edge case (JWT expired + user logs out before providing a refresh) and the overall security posture of the IV feature prevents worse outcomes, but it may be worth documenting or handling explicitly — for example, by skipping the JWT gate for the unsubscribe-on-logout operation. Not blocking the PR.

The implementation is solid. All critical issues are resolved and the approach is well-structured. The IdentityVerificationService / OperationRepo / JwtTokenStore responsibilities are cleanly separated.

nan-li · 2026-03-31T08:19:47Z

@claude re-review

claude · 2026-03-31T08:20:06Z

Claude finished @nan-li's task in 2m 39s —— View job

Re-review: feat/identity_verification_5.8

Read current state of key files
Verify fixes for the 2 observations from previous review
Look for any remaining or new issues
Post updated review

Both remaining observations from the previous re-review have been addressed. The PR is clean.

Previously Non-blocking — Now Fixed ✅

A. _jwtInvalidatedHandler not @Volatile (OperationRepo.kt:47)

Fixed in commit 76dd958. The field is now correctly annotated:

@Volatile
private var _jwtInvalidatedHandler: ((String) -> Unit)? = null

B. Expired JWT at logout blocks the push subscription disable (UpdateSubscriptionOperation.kt:89)

Fixed in commit 130aa16. The first approach (skip in LogoutHelper) was tried and reverted; the final solution is cleaner — it adds Operation.requiresJwt: Boolean = true as an open property on the base class and overrides it in UpdateSubscriptionOperation:

// Operation.kt:69
open val requiresJwt: Boolean get() = true

// UpdateSubscriptionOperation.kt:89
override val requiresJwt: Boolean get() = false

OperationRepo.hasValidJwtIfRequired() short-circuits on !op.requiresJwt, so subscription updates always proceed regardless of JWT state. This is backend-aligned — the subscription endpoint doesn't enforce JWT auth — and the executor still passes the JWT opportunistically when one is available (val jwt = lastOperation.externalId?.let { _jwtTokenStore.getJwt(it) }).

Minor Observation (no action needed)

The requiresJwt = false behavior on UpdateSubscriptionOperation has no dedicated test in OperationRepoTests. The behavior is implicitly covered by LogoutHelperTests, but a unit test verifying that an operation with requiresJwt = false executes when hasValidJwtIfRequired would otherwise block could add confidence. Given the simplicity of the change, this is not blocking.

The implementation is solid. All six issues identified across both review passes are resolved. The architecture is clean: IdentityVerificationService / OperationRepo / JwtTokenStore responsibilities are well-separated, the requiresJwt flag gives per-operation control over JWT gating, and the developer-facing callback round-trip is fully wired. Good to merge.

examples/demo/app/src/main/java/com/onesignal/sdktest/ui/main/MainViewModel.kt

OneSignalSDK/detekt/detekt-baseline-core.xml

abdulraqeeb33 · 2026-03-31T17:08:48Z

OneSignalSDK/detekt/detekt-baseline-in-app-messages.xml

  <CurrentIssues>
    <ID>ComplexCondition:InAppMessagesManager.kt$InAppMessagesManager$!message.isTriggerChanged &amp;&amp; isMessageDisplayed &amp;&amp; (isTriggerOnMessage || isNewTriggerAdded &amp;&amp; isOnlyDynamicTriggers)</ID>
-    <ID>ComplexMethod:TriggerController.kt$TriggerController$private fun evaluateTrigger(trigger: Trigger): Boolean</ID>
+    <ID>ComplexMethod:InAppMessagesManager.kt$InAppMessagesManager$private suspend fun fetchMessages(rywData: RywData)</ID>


we should break it down if its a complex method.

Yes, I undid the detekt changes and then added them back in the last few commits with reasoning. I actually didn't end up making changes to in-app-messages in detekt.

...al/core/src/main/java/com/onesignal/core/internal/config/impl/IdentityVerificationService.kt

...DK/onesignal/core/src/main/java/com/onesignal/user/internal/operations/LoginUserOperation.kt

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/user/internal/LogoutHelper.kt

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/user/internal/UserManager.kt

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/user/UserModule.kt

abdulraqeeb33 · 2026-03-31T18:11:01Z

OneSignalSDK/onesignal/core/src/main/java/com/onesignal/IOneSignal.kt

+     * @param externalId The external ID of the user whose token is being updated.
+     * @param token The new JWT bearer token.
+     */
+    fun updateUserJwt(


like i mentioned elsewhere, we need suspend methods for these

…ication nullable, OptionalHeaders.jwt Foundational models and infrastructure for identity verification: - Create JwtTokenStore: persistent Map<externalId, JWT> backed by SharedPreferences, supporting multi-user JWT storage with getJwt/putJwt/invalidateJwt/pruneToExternalIds - Add var externalId to Operation base class so OperationRepo can stamp and gate operations per-user; remove redundant externalId from LoginUserOperation and TrackCustomEventOperation (same Model data-map key, no migration needed) - Change ConfigModel.useIdentityVerification from Boolean to Boolean? (null = unknown, false = off, true = on) to eliminate race between operation processing and remote params - Add jwt field to OptionalHeaders for passing Bearer tokens through HTTP layer - Add PREFS_OS_JWT_TOKENS key to PreferenceOneSignalKeys Made-with: Cursor

…ion Bearer header to HttpClient Identity verification: plumb JWT through the HTTP and backend layer. - HttpClient: set Authorization: Bearer header when OptionalHeaders.jwt is non-null - IIdentityBackendService + impl: add jwt param to setAlias, deleteAlias - ISubscriptionBackendService + impl: add jwt param to createSubscription, updateSubscription, deleteSubscription, transferSubscription, getIdentityFromSubscription - IUserBackendService + impl: add jwt param to createUser, updateUser, getUser - All jwt params default to null so existing callers are unaffected

…D handling to OperationRepo Identity verification: OperationRepo becomes JWT-aware. - Add JwtTokenStore and IdentityModelStore as constructor dependencies - Centralized externalId stamping: internalEnqueue() auto-sets op.externalId from the current identity model for new operations (not loaded from persistence, not already set by the operation's constructor) - IV gating in getNextOps(): when IV=null (unknown), hold ALL operations; when IV=true, skip operations without a valid JWT; when IV=false, proceed normally - FAIL_UNAUTHORIZED: invalidate the per-user JWT in JwtTokenStore and re-queue operations to front (held by JWT gating until a new JWT is provided) - Cold-start cleanup: prune JwtTokenStore to externalIds from pending operations plus the current identity model's externalId - New removeOperationsWithoutExternalId() method on IOperationRepo for IdentityVerificationService to purge anonymous operations when IV is enabled

…tity verification - Add resolveIdentityAlias() helper to dynamically choose external_id vs onesignal_id for API paths - Each executor now looks up JWT from JwtTokenStore using operation's externalId and passes it to backend calls - LoginUserFromSubscriptionOperationExecutor returns FAIL_NORETRY when IV is enabled (v4 migration safety net) Made-with: Cursor

- Add jwt param to IInAppBackendService.listInAppMessages and pass through OptionalHeaders - Skip IAM fetch when identity verification is enabled and user is anonymous - Look up JWT from JwtTokenStore for authenticated IAM requests Made-with: Cursor

…subscriptions/:subscription_id/iams Made-with: Cursor

… and subscription listeners - LoginHelper: store JWT unconditionally on login, handle same-externalId re-login (store + forceExecute), set existingOneSignalId to null when IV=ON - LogoutHelper: IV=ON branch opts out push before user switch so backend is notified, then creates local-only anonymous user with suppressBackendOperation - UserManager: add jwtInvalidatedNotifier EventProducer for JWT callbacks - OneSignalImp: wire updateUserJwt, addUserJwtInvalidatedListener, removeUserJwtInvalidatedListener; pass JwtTokenStore/SubscriptionModelStore to LoginHelper/LogoutHelper - SubscriptionModelStoreListener, IdentityModelStoreListener, PropertiesModelStoreListener: suppress ops for anonymous users when IV=ON Made-with: Cursor

- New IdentityVerificationService: listens for config HYDRATE events, purges anonymous operations when IV=true, wakes OperationRepo when IV resolves from null, fires UserJwtInvalidatedEvent for beta migration (externalId present but no JWT) - CoreModule: register JwtTokenStore and IdentityVerificationService - ParamsBackendService: remove leftover TODO comments Made-with: Cursor

Register for JWT invalidation events, log a warning and show a toast when triggered.

Optional headers (ETag, RYW-Token, Retry-Count, Session-Duration, Authorization) were set after the body write, which opens the connection. This caused IllegalStateException on POST requests with a JWT. Move all setRequestProperty calls before outputStream write to prevent the error. Made-with: Cursor

Cache the JWT token on login and updateUserJwt calls. When Identity Verification is enabled, include the Authorization Bearer header in the demo app's fetch user request.

When Identity Verification is ON and logout is called, the SDK now sets isDisabledInternally=true instead of optedIn=false. This preserves the real opt-in preference while telling the backend the subscription is disabled. On the next login, UserSwitcher creates a fresh SubscriptionModel that defaults isDisabledInternally=false, restoring the real state automatically. Made-with: Cursor

Add addJwtInvalidatedListener, removeJwtInvalidatedListener, and fireJwtInvalidated methods to UserManager. Callers no longer need to cast IUserManager to UserManager to access the notifier directly. Register UserManager as a concrete DI service so IdentityVerificationService can depend on it directly. Made-with: Cursor

Made-with: Cursor

When OperationRepo handled FAIL_UNAUTHORIZED it invalidated the JWT and re-queued operations but never fired IUserJwtInvalidatedListener, leaving the queue permanently stuck. Wire a callback from OperationRepo through IdentityVerificationService to UserManager.fireJwtInvalidated() so the developer is notified and can supply a fresh token. Made-with: Cursor

Follow-up operations returned by executors (e.g. RefreshUserOperation) were inserted directly into the queue without externalId, causing them to be permanently blocked when identity verification is enabled. Made-with: Cursor

The externalId was being stamped inside internalEnqueue which runs on the OperationRepo coroutine thread. When LogoutHelper set isDisabledInternally=true (triggering an UpdateSubscriptionOperation) then immediately called createAndSwitchToNewUser(), the identity model's externalId could be cleared before the coroutine ran, leaving the operation with externalId=null and permanently blocked. Move stamping to enqueue()/enqueueAndWait() on the caller's thread so the externalId is captured at the moment the operation is created. Made-with: Cursor

Wrap JSONObject parsing in ensureLoaded() with try-catch so that corrupted persisted data (e.g. from a process kill mid-write) does not permanently break JWT lookups and stall the operation queue. Made-with: Cursor

When the server omits jwt_required from the params response, safeBool() returned null, leaving useIdentityVerification unset. getNextOps() treated null as "not yet known" and returned null permanently, silently blocking every SDK operation for the session. Default to false when the field is absent so non-IV apps are unaffected by the identity verification gating logic. Made-with: Cursor

The field is written from the main thread in IdentityVerificationService.start() and read on the OperationRepo coroutine thread. @volatile guarantees cross-thread visibility. Made-with: Cursor

When IV is enabled and the JWT has already been invalidated (e.g. by a prior 401), the UpdateSubscriptionOperation to disable the push subscription would be permanently blocked by hasValidJwtIfRequired. Since the backend call would fail with 401 anyway, skip it entirely and just switch to the new anonymous user. Made-with: Cursor Revert "Skip push subscription disable on logout when JWT is already expired" This reverts commit 5ce284257b6e03b8c862745ff58fcf4293299577. Exempt UpdateSubscriptionOperation from JWT gating The subscription update endpoint does not require a JWT on the backend. Add Operation.requiresJwt (default true) and override it to false in UpdateSubscriptionOperation so these operations are not blocked by hasValidJwtIfRequired when the JWT is expired or missing. This fixes the edge case where logging out with an expired JWT would permanently block the push subscription disable operation. Made-with: Cursor

Made-with: Cursor

…ationRepo Pass externalId alongside onesignalId in every operation constructor, eliminating the fragile stampExternalId workaround and parentExternalId propagation from OperationRepo. Every creation site (model store listeners, session listener, executors, etc.) now explicitly provides the externalId at construction time. Made-with: Cursor

Add suspend variant of updateUserJwt for API consistency with login/loginSuspend. Also add waitForInit to the non-suspend updateUserJwt so it safely handles calls before SDK initialization.

- Baseline 2 new UseCheckOrError entries for OneSignalImp.kt for updateUserJwt/updateUserJwtSuspend init guards that follow the existing login/logout pattern. - Baseline ReturnCount for hasValidJwtIfRequired — the guard-clause style is clearer than collapsing into a single boolean expression for this JWT gating logic. - Narrow JwtTokenStore catch from Exception to JSONException to satisfy detekt's TooGenericExceptionCaught rule, no baseline added.

…r params All new _prefix constructor parameters (e.g. _jwtTokenStore, _identityModelStore, _configModelStore) follow the existing codebase convention — 80+ identical entries already exist in the baseline. These are DI-injected dependencies across IdentityVerificationService, OperationRepo, JwtTokenStore, and various executors/listeners.

- Update 4 existing baseline entries (added jwt/_jwtTokenStore to signatures) - Baseline 4 new LongParameterList entries for IV constructors: CreateSubscriptionOperation, UpdateSubscriptionOperation, RefreshUserOperationExecutor, and UpdateUserOperationExecutor crossed the constructor threshold (8) after adding externalId and _jwtTokenStore params. This follows existing patterns.

OperationRepo: on FAIL_UNAUTHORIZED, invalidate JWT and re-queue before notifying the app; invoke setJwtInvalidatedHandler synchronously with try/catch so listener failures do not hit executeOperations outer catch. UserManager.fireJwtInvalidated performs the single async hop (SupervisorJob + Dispatchers.Default) with Otel-style launch try/catch and per-listener isolation. IdentityVerificationService: call forceExecuteOperations before fireJwtInvalidated on HYDRATE. Documentation: IOperationRepo handler runs on the op-repo thread and must return quickly; public API documents background-thread delivery for IUserJwtInvalidatedListener, addUserJwtInvalidatedListener, and UserJwtInvalidatedEvent (LiveData postValue guidance). Tests: FAIL_UNAUTHORIZED JWT handler coverage; no artificial delay after sync repo handler.

…2600) Co-authored-by: AR Abdul Azeez <abdul@onesignal.com>

abdulraqeeb33

Lets try and do a bug bash on this today/tomorrow?

nan-li changed the title ~~Feat/identity verification 5.8~~ Feat: identity verification 5.8 Mar 30, 2026

nan-li changed the title ~~Feat: identity verification 5.8~~ feat: identity verification 5.8 Mar 30, 2026

nan-li force-pushed the feat/identity_verification_5.8 branch from 4509a8f to 457b745 Compare March 30, 2026 09:35

claude bot reviewed Mar 30, 2026

View reviewed changes

nan-li force-pushed the feat/identity_verification_5.8 branch 4 times, most recently from 113e96b to 00d3799 Compare March 30, 2026 23:05

nan-li force-pushed the feat/identity_verification_5.8 branch from 972eace to f6e4227 Compare March 31, 2026 08:49

nan-li requested a review from a team March 31, 2026 16:01

abdulraqeeb33 requested changes Mar 31, 2026

View reviewed changes

nan-li added 15 commits April 2, 2026 12:10

add public API to interface

33c5300

Use alias-based IAM fetch endpoint: /users/by/:alias_label/:alias_id/…

1d85f7f

…subscriptions/:subscription_id/iams Made-with: Cursor

demo app: add JWT to buttons (login, updateJWT)

59215a3

Register for JWT invalidation events, log a warning and show a toast when triggered.

update remote params identity verification key to "jwt_required"

82b5341

demo app: use Identity verification toggle to make requests

e67ca19

Cache the JWT token on login and updateUserJwt calls. When Identity Verification is enabled, include the Authorization Bearer header in the demo app's fetch user request.

nan-li added 18 commits April 2, 2026 12:10

debug: dump full operation queue in OperationRepo log

0125f76

Made-with: Cursor

Fix spotless import ordering in CoreModule and UserManager

436ba14

Made-with: Cursor

Fix unit test compilation for identity verification parameters

8c047f9

Made-with: Cursor

Fix demo app stalling on failed login by dismissing loading immediately

83523a2

Made-with: Cursor

Harden JwtTokenStore against corrupted SharedPreferences data

9d1ad8f

Wrap JSONObject parsing in ensureLoaded() with try-catch so that corrupted persisted data (e.g. from a process kill mid-write) does not permanently break JWT lookups and stall the operation queue. Made-with: Cursor

Add @volatile to _jwtInvalidatedHandler for JMM visibility

1846e87

The field is written from the main thread in IdentityVerificationService.start() and read on the OperationRepo coroutine thread. @volatile guarantees cross-thread visibility. Made-with: Cursor

Add identity verification manual test plan

3e3086c

Made-with: Cursor

Update IDENTITY_VERIFICATION_MANUAL_TEST_PLAN.md

26de8e5

Add KDoc to hasValidJwtIfRequired explain gating

aff605b

fireJwtInvalidated off main

8b460e7

nit: update formatting

c57b0fa

Add updateUserJwtSuspend and waitForInit to updateUserJwt

16ce7f6

Add suspend variant of updateUserJwt for API consistency with login/loginSuspend. Also add waitForInit to the non-suspend updateUserJwt so it safely handles calls before SDK initialization.

nan-li force-pushed the feat/identity_verification_5.8 branch from b9b637d to 16ce7f6 Compare April 2, 2026 19:10

nan-li added 3 commits April 2, 2026 13:18

nan-li force-pushed the feat/identity_verification_5.8 branch from 1de75fa to cdc61b8 Compare April 2, 2026 20:25

nan-li force-pushed the feat/identity_verification_5.8 branch from ca64cdf to 258c8e6 Compare April 3, 2026 03:46

nan-li requested a review from abdulraqeeb33 April 3, 2026 06:57

fix: login race condition and JWT FAIL_UNAUTHORIZED blocking callers (#…

a292935

…2600) Co-authored-by: AR Abdul Azeez <abdul@onesignal.com>

abdulraqeeb33 approved these changes Apr 9, 2026

View reviewed changes

Conversation

nan-li commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

One Line Summary

Details

Motivation

Scope

Testing

Unit testing

Manual testing

Affected code checklist

Checklist

Overview

Testing

Final pass

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nan-li commented Mar 31, 2026

Uh oh!

claude bot commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Re-review: feat/identity_verification_5.8

Previously Critical — Now Fixed ✅

Remaining Observations (non-blocking)

Uh oh!

nan-li commented Mar 31, 2026

Uh oh!

claude bot commented Mar 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Re-review: feat/identity_verification_5.8

Previously Non-blocking — Now Fixed ✅

Minor Observation (no action needed)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

abdulraqeeb33 Mar 31, 2026

Choose a reason for hiding this comment

Uh oh!

nan-li Apr 2, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

abdulraqeeb33 Mar 31, 2026

Choose a reason for hiding this comment

Uh oh!

nan-li Apr 2, 2026

Choose a reason for hiding this comment

Uh oh!

abdulraqeeb33 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nan-li commented Mar 30, 2026 •

edited

Loading

claude bot commented Mar 31, 2026 •

edited

Loading

claude bot commented Mar 31, 2026 •

edited

Loading