fix: prevent a stale teardown from affecting a newer session generation

[Timo972]

+killActiveSessionAndWaitForTeardown waits at most FB_KILL_WAIT_TIMEOUT_SEC (35s) for an in-progress teardown, then proceeds regardless. A worst-case teardown is already close to that budget:

• up to 20s in stopScreenRecordingWithUUID: (STOP_SCREEN_RECORDING_TIMEOUT_SEC)
• up to 5s in -fb_isTestedApplicationSameAsSystemAppWithTimeout:
• up to 5s in -fb_terminateTestedApplicationWithTimeout:

plus the notification post and -disableAlertsMonitor. So ~30s of bounded work against a 35s wait — an overrunning teardown can still be mid-flight when POST /session gives up waiting and starts a replacement session.

The remaining teardown steps then mutate process-wide state on behalf of a session that is already gone:

• [application terminate] — the replacement session usually runs the same bundle identifier, so "terminate the old app" terminates the new session's app. The existing isAllowedToTerminate guard only covers the terminate step overrunning its own 5s timeout, not the overall wait having expired.
• the screen-recording cleanup — the promise is read out of FBScreenRecordingContainer.sharedInstance at teardown time, so by then it can already be the replacement session's. Both the stopScreenRecordingWithUUID: and the reset can therefore hit the new session's recording rather than the old one.

This adds a session generation counter, bumped in +killActiveSessionAndWaitForTeardown — i.e. at the moment a caller takes ownership of the device, before it launches anything, since the launch window is itself long enough for a stale teardown to do damage. -kill captures the generation it started with, and each step that mutates shared state re-checks it via +isSessionGenerationCurrent:. The terminate check happens inside the main-queue block rather than before dispatching, since that block is exactly where the unbounded delay occurs; the recording cleanup is skipped as a whole, covering the stop as well as the reset.

Because the wait is bounded, teardowns can genuinely overlap, so -kill's in-progress marker is a count rather than a flag — otherwise the first teardown to finish would wake waiters while another was still running.

_activeSession, the teardown count and the generation are all guarded by a single lock (+teardownCondition), and -kill clears the active session and registers its teardown in one critical section. Without that, a concurrent session creation could observe neither an active session nor a registered teardown, skip its wait, and start launching before the old teardown had registered itself. The lock is only ever held for those short transitions — never across the teardown work, the main-queue dispatch, or the bounded wait.

🤖 Generated with Claude Code

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Timo972 / name: timo (1bb8107, 7f533d5, 83a8ae7, b5da14b)

[Timo972]

Follow-up commit: _isTeardownInProgress is now a count rather than a boolean.

Since the wait in +killActiveSessionAndWaitForTeardown is bounded, two teardowns can genuinely overlap — a replacement session can be created while an earlier teardown is still finishing, and then be torn down itself. Sharing one flag meant the first teardown to finish cleared it and woke waiters while the second was still running; the next session creation could then bump the generation and cause that still-running teardown to skip terminating its app and resetting the recording container. So the generation guard in this PR closed the dangerous direction (killing the new session's app) but left the opposite one (the old app never being cleaned up at all).

Waiters now block until the count reaches zero, i.e. until every in-flight teardown has finished.

[Timo972]

Follow-up commit: the generation is now claimed in +killActiveSessionAndWaitForTeardown instead of in +markSessionActive:.

The guard was being claimed too late to protect the thing it was meant to protect. +handleCreateSession: calls +killActiveSessionAndWaitForTeardown before -prepareApplicationForSessionWithBundleID:, but +markSessionActive: only runs after the application has been launched. So when the bounded wait expired with a teardown still in flight, that teardown still saw its own generation as current for the whole launch window — and could terminate the process that had just been launched, which normally shares the old session's bundle identifier.

Claiming it at the moment a caller takes ownership of the device closes that window. A teardown that the call actually ran to completion is already finished, so invalidating it there is a no-op.

[github-actions]

🎉 This PR is included in version 16.11.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀