fix: prevent stale FetchUser from clobbering the current user's identity

[nan-li]

Description

One Line Summary

Stop a stale Fetch User call from clearing the current user's data, which was dropping the external_id set by login() and orphaning subsequent properties updates on that user.

Details

Motivation

Reported by a customer who added the SDK in an app update, then called login + addEmail, and sometimes the emails landed on the wrong anonymous user and the login silently failed.

Root cause is an ordering race in OSUserExecutor: when an on-new-session OSRequestFetchUser for a previous user (a cached anonymous user) is still pending and login() switches the current user, the in-flight Fetch User's success handler called clearUserData() unconditionally, wiping the external_id that login() had just set on the new current user. The following user-2 (409) conflict recovery then built an OSRequestCreateUser with external_id: nil, minting a stray anonymous user and dropping the login.

#1669 (the prewarm fix) makes this reproduction now very hard to hit (by deferring user creation until after first unlock it restores the normal launch ordering where no on-new-session Fetch User races ahead of login) but it does address the root issue. The stale-fetch clobber still occurs any time a Fetch User is pending ahead of a login()-driven request (e.g. a programmatic login() right after initialize, or slow network), no prewarm required.

Scope

• executeFetchUserRequest now early-returns when the fetched user is no longer the current user, which is safe, a stale response is discarded rather than clearing/hydrating the now-current user.
• parseFetchUserResponse is unchanged, as it is also used by the Create User path that remains unaffected.
• No public API changes.

Testing

Unit testing

Added two regression tests in UserExecutorTests:

• testFetchUser_forNonCurrentUser_doesNotClearCurrentUserData — a stale fetch must not clear the current user (fails before this fix, passes after).
• testFetchUser_forCurrentUser_stillClearsStaleData — the normal current-user fetch still clears + hydrates.

Full UserExecutorTests and SwitchUserIntegrationTests pass.

Manual testing

The original bug was captured in repro logs (FetchUser running ahead of IdentifyUser → CreateUser with external_id: nil). The race is now reproduced deterministically by the unit test above; reproducing the prewarm-triggered timing reliably on-device is impractical.

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