test: make workspace-switch and kit-registry concurrency tests deterministic

[nickolas-dimitrakas]

Stacked on #867. Review that one first — this PR's base is ci/bound-simulator-and-network-hangs, so the diff here is only the test changes.

Why

These are the two tests that repeat most often in the ObjC crash failures blocking CI:

• MParticleTests.testSwitchWorkspaceKitsWithStop
• MPKitContainerTests.testActiveKitsRegistryThreadSafety

They turned out to have two completely different problems, and only one of them is a test problem.

testSwitchWorkspaceKitsWithStop — genuinely a bad test

It waited on two nested hard-coded 10-second dispatch_after blocks, so it always burned at least 20 seconds of wall clock and depended on fixed timing rather than on the SDK actually being ready. Under CI load, "10 seconds is surely enough" is exactly the assumption that produces flakes.

It now waits on the SDK's own readiness signals — MParticle.initialized after startWithOptions:, then the replacement shared instance after switchWorkspaceWithOptions: — by spinning the main run loop until the condition holds, so main-queue work the SDK schedules still runs.

The assertions are unchanged. Same behaviour checked, no weakening.

	Before	After
testSwitchWorkspaceKitsWithStop	20.2s	0.11s

Verified: 3/3 runs of the test alone, and 4/4 runs of the whole MParticleTests class (62 tests, 0 failures).

MParticle.initialized is exposed to the test via the existing @interface MParticle () block, alongside the privates already redeclared there. No product change.

testActiveKitsRegistryThreadSafety — the test is right, the SDK is wrong

This one is not flaky tooling. It is correctly catching a real data race, reproduced at 2 crashes in 10 runs of that test on its own, nothing else running.

flushSerializedKits (MPKitContainer.m:217) fast-enumerates kitsRegistry and mutates it through freeKit: on the main queue without taking kitsSemaphore — the lock every other accessor of that set uses. activeKitsRegistry reads it under the semaphore; configureKits: mutates it under the semaphore. And configureKits:nil reaches the unlocked flush via an early return before the lock is acquired (MPKitContainer.m:2027) — precisely what the test calls in a loop while three threads read the registry.

So the crash is mutation-during-enumeration on shared state, and the test is doing its job.

What this PR does and does not do

Fixed here (test-side defects, real but not the cause of the crash):

• encounteredError was a plain __block BOOL written from four concurrent blocks — an unsynchronized flag is itself a data race. Now guarded by an NSLock, recording only the first exception.
• XCTFail was called from those background queues, which is not safe with XCTest. Failures are now reported from the dispatch_group_notify block on the main queue.

Not fixed here: the race itself. This test will still flake at roughly its current rate until MPKitContainer locking is addressed. That is deliberate — a core-concurrency change in a public SDK does not belong in a CI-stabilization PR, and AGENTS.md asks for coordination on anything touching the kit interface.

Notes for whoever takes the race

Groundwork already checked:

• All three flushSerializedKits callers (mParticle.m:611, mParticle.m:722, MPKitContainer.m:2029) are outside locked regions, so taking kitsSemaphore there would not deadlock.
• There is no dispatch_sync to the main queue inside any locked region.
• freeKit: must stay lock-free: configureKits: already calls it while holding the semaphore, and dispatch_semaphore is not recursive.
• The naive fix (wrap the main-queue flush in the semaphore) would let a long background critical section stall the main thread — the locked regions at 1149–1624 and 1656–1939 are large. Snapshotting the registry under the lock and iterating the snapshot off-lock avoids that, but freeKit: would still read kitsRegistry unlocked, so it is only a partial fix.

Scope left alone

testSwitchWorkspaceOptions and the other tests in that family still use the 10-second WORKSPACE_SWITCHING_DELAY (three nested delays, ~30s). The macro is retained for them. The same treatment would cut roughly another 60s off the ObjC suite, but they were not among the tests flagged as flaky, so they are out of scope here.

No CHANGELOG.md entry: test-only, no consumer-facing SDK change.

🤖 Generated with Claude Code

[cursor]

PR Summary

Low Risk
Changes are limited to unit tests; assertions are preserved and no shipping SDK code paths are modified.

Overview
Test-only CI stabilization for two frequently failing ObjC tests, with no production SDK behavior changes.

testSwitchWorkspaceKitsWithStop drops nested fixed 10s dispatch_after delays in favor of MPWaitForCondition, which spins the main run loop until MParticle.initialized after startWithOptions: and until a new shared instance is initialized after switchWorkspaceWithOptions:. Same assertions (kit with stop stays in the registry); runtime drops from ~20s to sub-second under load.

testActiveKitsRegistryThreadSafety fixes test harness issues: the shared error flag is now NSLock-protected, and XCTFail runs on the main queue in dispatch_group_notify instead of from concurrent worker blocks. It does not fix the underlying MPKitContainer race (flushSerializedKits vs activeKitsRegistry / configureKits:); that test can still crash until kit locking is addressed separately.

The MParticle test category gains initialized (already public on the class) and trims unused private method declarations.

^{Reviewed by Cursor Bugbot for commit 0a33db8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

📦 SDK Size Impact Report

Measures how much the SDK adds to an app's size (with-SDK minus without-SDK).

Metric	Target Branch	This PR	Change
App Bundle Impact	1.81 MB	1.81 MB	+N/A
Executable Impact	848 bytes	848 bytes	+N/A
XCFramework Size	6.51 MB	6.51 MB	+N/A

➡️ SDK size impact change is minimal.

Raw measurements

Target branch (main):

{"baseline_app_size_kb":84,"baseline_executable_size_bytes":75464,"with_sdk_app_size_kb":1936,"with_sdk_executable_size_bytes":76312,"sdk_impact_kb":1852,"sdk_executable_impact_bytes":848,"xcframework_size_kb":6664}

This PR:

{"baseline_app_size_kb":84,"baseline_executable_size_bytes":75464,"with_sdk_app_size_kb":1936,"with_sdk_executable_size_bytes":76312,"sdk_impact_kb":1852,"sdk_executable_impact_bytes":848,"xcframework_size_kb":6664}

[BrandonStalnaker]

This looks good but please make sure all the CI succeeds before merging