test: stress photo video output transitions

Author: mrousavy

START_CRASH_FINDINGS.md

@@ -6,9 +6,9 @@ Branch: `codex/start-crash-3773`
 
 ## Current status
 
-This branch contains an event-driven reproducer in the simple-camera app and an iOS Harness stress test. I have not produced the exact AVFoundation assertion locally or in CI yet. The local multi-physical-camera iPhone 15 Pro became locked and SpringBoard denied further launches, while the available iPhone SE 3rd gen ran the repro loop without crashing. The first CI iOS Harness run also ran the new 120-cycle repro on a multi-camera iOS Device Farm device without crashing.
+This branch contains an event-driven reproducer in the simple-camera app and an iOS Harness stress test. I have not produced the exact AVFoundation assertion locally or in CI yet. The local multi-physical-camera iPhone 15 Pro became locked and SpringBoard denied further launches, while the available iPhone SE 3rd gen ran the earlier repro loop without crashing. The first CI iOS Harness run also ran the earlier 120-cycle repro on a multi-camera iOS Device Farm device without crashing.
 
-The strongest confirmed root-cause evidence is therefore the original issue stack plus the VisionCamera call ordering below. The stack proves `AVCaptureSession.startRunning()` overlapped with AVFoundation's private configuration-commit notification path. The exact assertion condition inside `-[AVCaptureOutput attachToFigCaptureSession:]` is private Apple code, so the remaining internal invariant is inferred from the stack, not decompiled source.
+The strongest confirmed root-cause evidence is therefore the original issue stack plus the VisionCamera call ordering below. The original stack proves `AVCaptureSession.startRunning()` overlapped with AVFoundation's private configuration-commit notification path. A separate client report mentions the sibling private assertion `AVCaptureOutput detachFromFigCaptureSession` during rapid `photo -> video -> photo` changes, especially with a filter-preview path involved. That client report is not a stack trace, but it is directionally important because it points at the same output lifetime boundary from the detach side rather than the attach side. The exact assertion conditions inside `-[AVCaptureOutput attachToFigCaptureSession:]` and `detachFromFigCaptureSession` are private Apple code, so the remaining internal invariant is inferred from stacks/logs, not decompiled source.
 
 ## What the crash stack proves
 
@@ -29,6 +29,8 @@ Because VisionCamera serializes `configure()` and `start()` on `HybridCameraSess
 6. AVFoundation is still attaching outputs from the committed configuration on `FigCaptureSessionNotificationQueue`.
 7. AVFoundation hits its private assertion in `attachToFigCaptureSession`.
 
+The newer client report describes `detachFromFigCaptureSession`, which is the same class of invariant violation during output teardown instead of output attachment. Taken together, the evidence points at AVFoundation output attachment/detachment lifetime crossing a session start or a subsequent output topology change. It does not point at JavaScript timing alone, and it does not prove that a single specific output type is always responsible.
+
 ## VisionCamera code path responsible
 
 Native serialization is in `packages/react-native-vision-camera/ios/Hybrid Objects/HybridCameraSession.swift`:
@@ -61,30 +63,31 @@ That is a valid VisionCamera queue order, but it is the exact dangerous order if
 The example app starts the camera automatically, then loops from native callbacks:
 
 1. `onStarted` sets `isActive=false`.
-2. `onStopped` swaps video output settings and optional HDR constraints.
+2. `onStopped` alternates the active output topology between photo-only and video-only.
 3. `onStopped` immediately sets `isActive=true`.
 4. The next React commit reconfigures outputs/constraints and restarts without sleeps.
 
-The loop attaches both photo and video outputs, alternates `HD_16_9`/`FHD_16_9` video output settings, requests 60 FPS when supported, requests cinematic-extended stabilization when supported, and toggles `photoHDR` when supported.
+The current loop uses `<SkiaCamera>` so the preview path is a frame output rendered through Skia rather than a native preview output. It alternates `photo -> video -> photo`, alternates `HD_16_9`/`FHD_16_9` video output settings, requests 60 FPS when supported, requests cinematic-extended stabilization during video cycles when supported, and toggles `photoHDR` during photo cycles when supported.
 
 This is intentionally event-driven. It does not use artificial sleeps or timeouts to create the race window.
 
 ## Harness reproducer added
 
-`apps/simple-camera/__tests__/visioncamera.camera-view.harness.tsx` now contains:
+`apps/simple-camera/__tests__/visioncamera.start-crash.harness.tsx` now contains two iOS-only stress tests:
 
 ```text
-reconfigures outputs and immediately restarts from Camera lifecycle callbacks
+cycles photo -> video -> photo outputs through native preview start/stop
+cycles photo -> video -> photo outputs with Skia frame-preview attached
 ```
 
-It renders a high-level `<Camera>` and runs 120 cycles of:
+They render high-level camera components and run 60 cycles of:
 
 ```text
 onStarted -> inactive
-onStopped -> replace video output + toggle constraints + active
+onStopped -> switch photo-only/video-only output topology + toggle constraints + active
 ```
 
-This is the closest Harness shape to the reported crash because it exercises the React hook lifecycle that can enqueue `configure()` followed by `start()` in the same commit. A crash on CI should appear as an iOS Harness process failure rather than a normal assertion failure.
+The first stress test uses the normal `<Camera>` native preview path. The second uses `<SkiaCamera>`, which always adds a frame output for preview rendering and therefore exercises the filter-preview shape mentioned in the newer client report. A crash on CI should appear as an iOS Harness process failure rather than a normal assertion failure.
 
 ## Device observations
 
@@ -100,16 +103,18 @@ Observed locally:
 - Subsequent iPhone 15 Pro launches were denied because the device was locked: `Unable to launch com.margelo.nitro.camera.example.simple because the device was not, or could not be, unlocked`.
 - The attached Teams video shows an app crash alert after an active video recording session, but it does not expose a native stack. It supports the general "active camera plus output/session state changes" trigger shape, not the internal AVFoundation diagnosis by itself.
 
-CI observations from PR #4001 / Harness AWS Device run `27018903509`:
+CI observations from PR #4001 / Harness AWS Device run `27018903509` for the earlier, now-replaced Harness repro:
 
 - Build iOS passed.
 - Test iOS executed on a multi-camera iOS device exposing wide, ultra-wide, telephoto, dual, dual-wide, triple, lidar-depth, and true-depth devices.
 - The new Harness test completed 120 cycles on `Back Camera` in 25.766s: `reconfigures outputs and immediately restarts from Camera lifecycle callbacks`.
 - iOS Harness summary was green: 12 test suites passed, 125 tests passed, 15 skipped, 0 failed.
 - The GitHub `Test iOS` job still reported failure because the Device Farm step itself returned failed, but the Harness output did not contain an AVFoundation crash, app crash, failed test, or assertion.
-- Android also ran the new test and completed 120 cycles in 27.414s. Android failed in unrelated existing suites (`photo`, `coordinates`, `controller`, `video`), not in the new Camera-view repro.
+- Android also ran the earlier test and completed 120 cycles in 27.414s. Android failed in unrelated existing suites (`photo`, `coordinates`, `controller`, `video`), not in the Camera-view repro.
+
+Why CI passed: that earlier Harness test was not equivalent to either report. It kept photo and video outputs attached together, then mostly recreated the video output and restarted. It did not remove the photo output before adding video, did not remove video before re-adding photo, did not use the Skia/filter-preview path, did not record video, and did not run on the original iPhone 11 / iOS 18.7.7 matrix. Its green result only proves that "replace video while photo remains attached, then restart" did not hit the assertion on that AWS device in 120 cycles.
 
-Negative evidence: the iPhone SE result and the first iOS Device Farm result suggest the current loop is not sufficient to deterministically reproduce the crash. Hardware/OS version, camera topology, recording state, recorder preparation, lens switching, mount/unmount timing, or a narrower output transition likely matters.
+Negative evidence: the iPhone SE result and the first iOS Device Farm result suggest the earlier loop was not sufficient to deterministically reproduce the crash. Hardware/OS version, camera topology, recording state, recorder preparation, lens switching, mount/unmount timing, or the narrower photo-only/video-only output transition likely matters.
 
 ## Verification done
 
@@ -122,15 +127,15 @@ git diff --check
 bun --cwd apps/simple-camera react-native bundle --platform ios --dev true --entry-file index.js --bundle-output /tmp/simple-camera-start-crash.bundle --assets-dest /tmp/simple-camera-start-crash-assets --reset-cache
 ```
 
-`bunx biome check apps/simple-camera/__tests__/visioncamera.camera-view.harness.tsx apps/simple-camera/src/screens/CameraScreen.tsx` reported only pre-existing unused-variable warnings in `CameraScreen.tsx`. The new Harness file had no Biome diagnostics.
+`bunx biome check apps/simple-camera/__tests__/visioncamera.start-crash.harness.tsx apps/simple-camera/__tests__/visioncamera.camera-view.harness.tsx apps/simple-camera/src/screens/CameraScreen.tsx START_CRASH_FINDINGS.md apps/simple-camera/__tests__/README.md` reported only pre-existing unused-variable warnings in `CameraScreen.tsx`. The new stress Harness file had no Biome diagnostics.
 
 Local `react-native-harness --harnessRunner ios` tried to boot an iOS simulator, so I stopped it. The simulator is not useful for this camera pipeline race; the PR CI iOS Harness run on real hardware is the relevant signal.
 
 ## Current root-cause statement
 
 The best current issue description is:
 
-> VisionCamera can enqueue `AVCaptureSession.startRunning()` immediately after a configuration commit that replaces outputs or changes output-affecting constraints. VisionCamera's own serial queue ensures `startRunning()` happens after `commitConfiguration()` returns, but AVFoundation/CoreMedia may still be processing the committed configuration asynchronously on `FigCaptureSessionNotificationQueue`. On affected hardware/OS combinations, `startRunning()` can overlap that private output-attachment work and trip AVFoundation's internal assertion in `-[AVCaptureOutput attachToFigCaptureSession:]`.
+> VisionCamera can enqueue `AVCaptureSession.startRunning()` immediately after a configuration commit that replaces outputs or changes output-affecting constraints. VisionCamera's own serial queue ensures `startRunning()` happens after `commitConfiguration()` returns, but AVFoundation/CoreMedia may still be processing the committed configuration asynchronously on `FigCaptureSessionNotificationQueue`. On affected hardware/OS combinations, `startRunning()` or a subsequent topology change can overlap that private output attachment/detachment work and trip AVFoundation's internal assertions in `-[AVCaptureOutput attachToFigCaptureSession:]` or `detachFromFigCaptureSession`.
 
 This is proven at the call-order/concurrency level by the crash stack and VisionCamera source. It is not yet proven at the "Apple internal field X had value Y" level because AVFoundation source is private and the exact assertion condition is not visible.
 

apps/simple-camera/__tests__/README.md

@@ -30,6 +30,7 @@ Tests are split by domain. Each file tests one slice of the imperative `VisionCa
 | [visioncamera.coordinates.harness.ts](visioncamera.coordinates.harness.ts) | `Frame.convertFramePointToCameraPoint` / `convertCameraPointToFramePoint`, `PreviewView.convertViewPointToCameraPoint` / `convertCameraPointToViewPoint`, `PreviewView.createMeteringPoint`, `convertScannedObjectCoordinatesToViewCoordinates`, end-to-end Frame → Camera → View round-trip |
 | [visioncamera.nativepreviewview.harness.tsx](visioncamera.nativepreviewview.harness.tsx) | Bare `NativePreviewView` lifecycle, layout-sensitive preview regression coverage, `resizeMode`, Android `implementationMode`, gesture controllers, multi-preview mounting, `PreviewView` ref methods, Android `takeSnapshot()` dimensions |
 | [visioncamera.camera-view.harness.tsx](visioncamera.camera-view.harness.tsx) | High-level `<Camera>` preview lifecycle, photo output integration, controller props, native gestures, `CameraRef` methods, `isActive`, mount / unmount / replacement behavior |
+| [visioncamera.start-crash.harness.tsx](visioncamera.start-crash.harness.tsx) | iOS AVFoundation output attach/detach stress repro for issue #3773, including photo -> video -> photo output topology and the Skia frame-preview path |
 
 Pick the file that best matches what you're testing. If you're reproducing a bug that spans multiple outputs, put it in the file most central to the failure. If nothing fits, open a new `visioncamera.<domain>.harness.ts` — Jest picks up anything matching `__tests__/**/*.harness.{ts,tsx}`.
 

apps/simple-camera/__tests__/visioncamera.camera-view.harness.tsx

@@ -1,4 +1,4 @@
-import { createRef, useCallback, useMemo, useState } from 'react'
+import { createRef } from 'react'
 import { type LayoutChangeEvent, StyleSheet } from 'react-native'
 import {
   afterEach,
@@ -9,12 +9,7 @@ import {
   it,
   render,
 } from 'react-native-harness'
-import type {
-  CameraDevice,
-  CameraRef,
-  Constraint,
-  Point,
-} from 'react-native-vision-camera'
+import type { CameraDevice, CameraRef, Point } from 'react-native-vision-camera'
 import {
   Camera,
   CommonResolutions,
@@ -433,104 +428,6 @@ describe('VisionCamera - Camera View', () => {
     expectPreviewGeometry(secondCamera, secondCameraLayout)
   })
 
-  it('reconfigures outputs and immediately restarts from Camera lifecycle callbacks', async () => {
-    const maxCycles = 120
-    const finished = deferred<number>()
-    let sessionError: Error | undefined
-
-    function RestartingCamera() {
-      const [isActive, setIsActive] = useState(true)
-      const [cycle, setCycle] = useState(0)
-      const [variant, setVariant] = useState(0)
-      const [enablePhotoHDR, setEnablePhotoHDR] = useState(false)
-
-      const photoOutput = useMemo(
-        () =>
-          VisionCamera.createPhotoOutput({
-            targetResolution: CommonResolutions.HD_4_3,
-            containerFormat: 'jpeg',
-            quality: 0.8,
-            qualityPrioritization: 'balanced',
-          }),
-        [],
-      )
-      const videoOutput = useMemo(
-        () =>
-          VisionCamera.createVideoOutput({
-            targetResolution:
-              variant % 2 === 0
-                ? CommonResolutions.FHD_16_9
-                : CommonResolutions.HD_16_9,
-            targetBitRate: variant % 2 === 0 ? 20_000_000 : 12_000_000,
-            enableAudio: false,
-          }),
-        [variant],
-      )
-      const outputs = useMemo(
-        () => [photoOutput, videoOutput],
-        [photoOutput, videoOutput],
-      )
-      const constraints = useMemo<Constraint[]>(() => {
-        const nextConstraints: Constraint[] = []
-        if (backDevice.supportsFPS(60)) {
-          nextConstraints.push({ fps: 60 })
-        }
-        if (backDevice.supportsVideoStabilizationMode('cinematic-extended')) {
-          nextConstraints.push({ videoStabilizationMode: 'cinematic-extended' })
-        }
-        if (enablePhotoHDR && backDevice.supportsPhotoHDR) {
-          nextConstraints.unshift({ photoHDR: true })
-        }
-        return nextConstraints
-      }, [enablePhotoHDR])
-      const onStarted = useCallback(() => {
-        setIsActive(false)
-      }, [])
-      const onStopped = useCallback(() => {
-        const nextCycle = cycle + 1
-        if (nextCycle >= maxCycles) {
-          console.log(
-            `start crash repro harness completed ${nextCycle} cycles on ${backDevice.localizedName}`,
-          )
-          finished.resolve(nextCycle)
-          return
-        }
-
-        setCycle(nextCycle)
-        setVariant((current) => current + 1)
-        setEnablePhotoHDR((current) => !current)
-        setIsActive(true)
-      }, [cycle])
-      const onError = useCallback((error: Error) => {
-        sessionError = error
-        finished.reject(error)
-      }, [])
-
-      return (
-        <Camera
-          device={backDevice}
-          isActive={isActive}
-          outputs={outputs}
-          constraints={constraints}
-          style={StyleSheet.absoluteFill}
-          onStarted={onStarted}
-          onStopped={onStopped}
-          onError={onError}
-        />
-      )
-    }
-
-    await render(<RestartingCamera />)
-    const cycles = await withTimeout(
-      finished.promise,
-      120_000,
-      'Camera output reconfigure/restart cycles',
-    )
-
-    expect(cycles).toBe(maxCycles)
-    expect(sessionError).toBe(undefined)
-  })
-
   it('fires stop callbacks when isActive is rerendered from true to false', async () => {
     const cameraRef = createRef<CameraRef>()
     const layout = deferred<Layout>()