[fadi-george]

Description

One Line Summary

Fix five flaky iOS unit tests that failed on CI across unrelated branches.

Details

Motivation

These tests failed intermittently on CI and blocked unrelated PRs (e.g. #1803):

• EarlyTriggerTrackingTests: a message displayed at the end of one test built its web view on the main queue during the next test. On a cold CI simulator that held the main thread for seconds, so the next test's observer callbacks (delivered via dispatch_async to main) missed the 5s wait and the IAM fetch never ran. Confirmed from the CI xcresult logs.
• SwitchUserIntegrationTests.testAnonUser_thenIdentifyUserWithConflict_thenLogin_...: relied on a 300ms poll interval to batch each user's tag and language into one request. A poll landing between addTag and setLanguage split them and failed the single-request assertion.
• FileLogStoreRecordDatingTests: the first file-store calls in the test process stalled for about 37s on CI, so whichever tests ran first hit their 5s waits. Confirmed from the CI xcresult; the exact cold-start source (likely first Kotlin runtime use) is not pinned down.
• IamFetchIdentityVerificationTests.testAFetchIsHeldRatherThanSentUnsignedWhenTheUserHasNoToken: the login helper returned once the mock client looked idle, but the IAM fetch the new subscription id starts can reach the client after that. The test then invalidated token-a, and the late fetch landed signed with token-a instead of the expected token-b. Seen on this PR's first CI run.
• CustomEventsIntegrationTests.testTrackEvent_withArrayProperties_sendsCorrectly: read executedRequests.first as the custom events request, but a late Fetch User from an earlier test reached the shared mock client first. Seen on this PR's second CI run.

Scope

Test-only changes:

• EarlyTriggerTrackingTests: pause in-app messaging in these tests via a startPausedController() helper. The isTriggerChanged flags are set before the pause check, so what the tests check is unchanged. Force unwraps replaced with XCTUnwrap so a failure doesn't crash and restart the whole suite.
• SwitchUserIntegrationTests: start, wait for the anonymous user to be created, pause the operation repo while queuing updates, then unpause and flush. This matches the sibling tests and drops the 300ms interval that leaked into later tests.
• IamFetchIdentityVerificationTests: login also waits for the fetch it triggers to be answered or held.
• Custom events tests: new MockOneSignalClient.firstExecutedRequest(ofType:) picks the request by type instead of position (7 call sites).
• FileLogStoreTestCase: class-level warm-up (up to 120s) absorbs the one-off cold start so per-test 5s timeouts stay meaningful. If the warm-up times out, each test fails in setup with a clear error.

Not included: UserJwtLifecycleTests flakes. Every failing run predates #1794 (123cbea13), which already fixed that race, and there have been no failures since.

Testing

Unit testing

On a temporary iOS 26.5 simulator, the same runtime CI uses:

• The changed test classes passed repeated runs (-test-iterations 3 to 10).
• The full UnitTestApp_TestPlan_Reduced passed (664 tests).

Because these flakes only show up under CI load, passing locally doesn't prove they're gone.

Manual testing

Not applicable; test-only change.

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

[nan-li]

approving since as test only and it is an improvement

One non-blocking note on the SwitchUser test. The pause is not exclusive: OSUserExecutor.swift:538 sets operationRepo.paused = false on every successful Create User, and login(A) produces one about 100ms after the call once the 409 turns into a create. If the test thread is still queuing past that point, a 100ms poll can land between addTag and setLanguage and split the request. The window is much smaller than before and the two sibling tests share it, so this is fine to land as is. If the test flakes again, that unpause is the first place to look.

[abdulraqeeb33]

The pause still sets isTriggerChanged before display is skipped, and the user-switch test now matches the sibling pause-and-flush. Two nits, neither blocks.

[abdulraqeeb33]

Approving. The two nits on the earlier comment are non-blocking.

[fadi-george]

@nan-li thanks, confirmed OSUserExecutor.swift:538 unpauses on create success. Leaving as is like the siblings; will look there first if it flakes again.