feat(jwt): Handle logout and fetch IAMs (6/6)

[nan-li]

Sixth and final PR re-implementing Identity Verification (IV) on the feat/identity_verification_feature_flagged_major_release integration branch.

Stack: #2623 → #2624 → #2625 → #2626 → #2633 → this

What this PR does

Wires IV-aware behavior for logout, read-your-write (RYW) consistency on login, and IAM fetch. Closes the loop on the customer-visible IV flows: a customer who configures jwt_required=true server-side now gets an SDK that signs requests, recovers from 401s when the developer supplies a fresh JWT, and keeps the IAM fetch consistent with the just-created user record.

All new code paths are gated by the two-layer pattern from #2625:

• Outer gate newCodePathsRun at the dispatch site → keeps Phase 1 customers byte-for-byte on the legacy flow.
• Inner gate ivBehaviorActive inside the *IvExtensions helpers → Phase 3 (new code path on, IV behavior off) exercises the structural plumbing without attaching JWTs or rewriting aliases.

Logout under IV-required

Under IV-required, the new device-scoped (anonymous) user cannot authenticate against the backend — there's no JWT for it. The legacy logout flow enqueues an anonymous LoginUserOperation plus a create-subscription op for the new push sub; both would 401 forever and permanently block the queue.

• New SubscriptionModel.isDisabledInternally flag (internal-only). SubscriptionModelStoreListener short-circuits to (false, UNSUBSCRIBE) when set, suppressing backend ops for the marked subscription.
• New LogoutHelperIvExtensions.switchUserIv: marks the current push sub as internally disabled and calls userSwitcher.createAndSwitchToNewUser(suppressBackendOperation = true). Returns true so LogoutHelper.switchUser skips the anonymous LoginUserOperation enqueue.
• LogoutHelper constructor takes subscriptionModelStore and identityVerificationService; outer-gates dispatch on newCodePathsRun. Phase 1/3 still walk the legacy createAndSwitchToNewUser() + LoginUserOperation enqueue.

RYW plumbing for IAM consistency

Under IV the backend returns a ryw_token (with optional ryw_delay_ms) on /users create. IAM fetch must await this token via IConsistencyManager so the in-app message list reflects the just-written user record.

• CreateUserResponse.rywData: RywData? — populated under IV, null otherwise.
• JSONConverter.convertToCreateUserResponse parses ryw_token / ryw_delay.
• LoginUserOperationExecutor.createUser sets the RYW data on ConsistencyManager for IamFetchRywTokenKey.USER, gated on newCodePathsRun. Phase 1 stays on existing behavior; Phase 3 exercises the parse + register path with no token attachment.

IAM IV integration

• New IInAppBackendService.listInAppMessagesIv(appId, aliasLabel, aliasValue, jwt?) alongside the legacy listInAppMessages(appId, subscriptionId) — alias-based URL (/apps/{appId}/users/by/{aliasLabel}/{aliasValue}/iams), Authorization: Bearer <jwt> when JWT non-null, throws BackendException on 401/403 so the manager can react.
• InAppMessagesManager injects JwtTokenStore + IdentityVerificationService and subscribes to JwtTokenStore as IJwtUpdateListener so a fresh JWT (via updateUserJwt from feat(jwt): public API — IUserJwtInvalidatedListener, updateUserJwt, login JWT (5/6) #2633) replays the deferred fetch.
• fetchMessages outer-gates on newCodePathsRun: dispatches to fetchIvOrSaveRetry under the new path, falls through to the legacy subscriptionId fetch otherwise.
• fetchIvOrSaveRetry inner-gates on ivBehaviorActive: under IV uses external_id + JWT (caches pendingJwtRetry{ExternalId,RywData} on 401 for replay); Phase 3 uses onesignal_id + null JWT (exercises the new endpoint structurally, no IV behavior).
• 401 from the IV fetch resets the rate-limiter so the listener-driven retry isn't throttled.
• Pending retry state is cleared on user-switch via the existing identityModelChangeHandler.onModelReplaced.

Cross-module visibility

The IAM module is a separate Gradle module, so a few core types had their internal modifier dropped to be Kotlin-visible cross-module: JwtTokenStore, IdentityVerificationService, IJwtUpdateListener, IFeatureManager, FeatureFlag, FeatureActivationMode. They remain package-internal by convention (.internal. paths).

Misc

Includes a small init-readiness fix on top of #2633: addUserJwtInvalidatedListener / removeUserJwtInvalidatedListener now match the updateUserJwt pattern (waitForInit when background threading is enabled, throw IllegalStateException otherwise) so listeners aren't silently bound to a not-yet-wired UserManager.

Testing

Unit testing

• Updated test fixtures for the new constructor params: LogoutHelperTests, LoginUserOperationExecutorTests, InAppMessagesManagerTests. Existing legacy-path assertions still pass; new helpers accept mocks for subscriptionModelStore, identityVerificationService, jwtTokenStore, and _consistencyManager with newCodePathsRun = false / ivBehaviorActive = false so legacy behavior is the default in tests.

Manual testing

• Logout while jwt_required=true: verify no anonymous LoginUserOperation is enqueued and the queue does not stall on 401s.
• IAM fetch under IV: verify the SDK awaits ryw_token from /users before issuing the alias-based fetch, attaches Authorization: Bearer <jwt>, and retries once updateUserJwt is called after a 401.
• Phase 1 / Phase 3 regressions: verify legacy IAM fetch and legacy logout flows are byte-for-byte unchanged when newCodePathsRun=false.

Affected code

• Public API: addUserJwtInvalidatedListener / removeUserJwtInvalidatedListener init guards (no signature change).
• In-App Messaging: new alias-based fetch endpoint + JWT retry path.
• REST API requests: new GET /apps/{appId}/users/by/{aliasLabel}/{aliasValue}/iams (IV path only).
• Logout flow: IV-specific user-switch that suppresses backend ops.

🤖 Generated with Claude Code

[claude]

🟡 Race window between the IAM-fetch 401 catch and a concurrent updateUserJwt can drop the pending JWT-retry state in InAppMessagesManager. The catch block at lines 401-402 sets pendingJwtRetryExternalId/RywData after the failed HTTP response arrives, so an onJwtUpdated firing during the in-flight window will read pending == null and return early — leaving pending state set with no future onJwtUpdated to consume it until an unrelated event re-triggers fetchMessagesWhenConditionIsMet. Practical impact is bounded (IAMs recover on next session / push-sub change / ConfigModel update); fix is to set pending before listInAppMessagesIv and clear on success, or guard the read-then-act and the catch's write under a single Mutex.

Extended reasoning...

Race condition

InAppMessagesManager.fetchIvOrSaveRetry (lines ~371-410) writes the pending-retry state after the backend call throws:

return try {
    _backend.listInAppMessagesIv(appId, aliasLabel, aliasValue, subscriptionId, rywData, sessionDurationProvider, jwt)
} catch (ex: BackendException) {
    if (ivBehaviorActive && externalId != null) {
        pendingJwtRetryExternalId = externalId   // ← written AFTER 401 response arrived
        pendingJwtRetryRywData = rywData
        ...
    }
    null
}

Meanwhile, onJwtUpdated (lines 419-425) reads-then-acts on the same fields:

override fun onJwtUpdated(externalId: String) {
    val pending = pendingJwtRetryExternalId
    val pendingRyw = pendingJwtRetryRywData
    if (pending == null || pending != externalId || pendingRyw == null) return
    ...
}

@Volatile makes individual reads/writes atomic but does not linearize the compound (catch writes pending) ↔ (onJwtUpdated reads pending) sequence.

How it manifests (step-by-step proof)

1. IAM fetch on coroutine A issues listInAppMessagesIv with a stale JWT — request in flight, pendingJwtRetryExternalId == null.
2. Concurrently, an unrelated OperationRepo op on coroutine B fails 401 → OperationRepo.handleFailUnauthorized invokes JwtTokenStore.invalidateJwt(externalId) → developers IUserJwtInvalidatedListener fires → developer responds with OneSignal.updateUserJwt(externalId, freshToken) → JwtTokenStore.putJwt → synchronously fires IInAppMessagesManager.onJwtUpdated (per EventProducer.fire, dispatched on the callers thread).
3. onJwtUpdated(externalId) runs now: reads pendingJwtRetryExternalId == null, returns at the early-exit. No retry scheduled.
4. Coroutine As 401 finally surfaces → catch block writes pendingJwtRetryExternalId = externalId and pendingJwtRetryRywData = rywData.
5. Pending state is set, but the developer has already supplied the fresh JWT — no further onJwtUpdated will fire for this externalId. The retry is orphaned.

The window is the entire HTTP round-trip of the in-flight IAM fetch (plus delay(rywDelay) ≥ 500 ms before it), not just the few µs between throw and field assignment that the refutation describes — the developers updateUserJwt can land at any point while the IAM request is in flight, since the request was issued before the JWT was rotated.

Why existing code does not prevent it

• fetchIAMMutex only guards the rate-limiter read/write at lines ~322-330; it is released before the network call.
• @Volatile provides per-field atomicity, not compound atomicity for the read-then-act vs. write sequence.
• The identityModelStore change handler that clears the pending fields only fires on user-switch, which is unrelated.

Impact

Bounded and recoverable: the deferred IAM fetch is silently delayed until the next fetchMessagesWhenConditionIsMet trigger (onSessionStarted, push subscription id change, ConfigModel.appId update, or onesignalId hydration). End-user visibility is "no IAMs displayed in this session" — they show on next cold start or session.

The refutation argues "not actionable for this PR." Three independent verifiers reviewed and all confirmed the race is real; they downgraded to nit because the impact is bounded and the trigger is uncommon, not because the bug is invalid. Filing as nit to match.

Suggested fix

Set the pending state before invoking listInAppMessagesIv and clear it on successful return. That makes onJwtUpdated see the pending fields any time during the in-flight window, regardless of when the response surfaces:

if (ivBehaviorActive && externalId != null) {
    pendingJwtRetryExternalId = externalId
    pendingJwtRetryRywData = rywData
}
return try {
    val result = _backend.listInAppMessagesIv(...)
    // success: clear pending
    pendingJwtRetryExternalId = null
    pendingJwtRetryRywData = null
    result
} catch (ex: BackendException) {
    // pending already set; just log
    ...
}

Alternatively, wrap onJwtUpdateds read+act and the catchs write under a single Mutex / synchronized block so they linearize.

[abdulraqeeb33]

please make this lazy