fix: Apply adaptiveness metering modes before resolving focusTo(…)

[mrousavy]

Fixes the Harness iOS failure on main introduced with the test from #4078 (locks metering modes after focusTo with locked adaptiveness, expected 'continuous-auto-white-balance' to be 'locked').

Root cause: In MeteringTask.update(), once all metering states settled, onComplete?() resolved the JS Promise before setMeteringValuesToLocked()/...Continuous() applied the final modes. The JS continuation's synchronous controller.whiteBalanceMode read raced ahead of the camera queue's lockForConfiguration() + mode set and still saw continuous-auto-white-balance. The AF/AE asserts masked this because snappy metering uses one-shot .autoFocus/.autoExpose, which AVFoundation auto-transitions to .locked on settle - AWB running in continuous mode only becomes locked through the explicit (late) set. This failed identically on #4078's own CI run, so it lost the race deterministically on the CI iPhone.

Fix: Reorder the completion sequence: mark isFinished, tear down KVO observers/timers, apply the adaptiveness modes, then resolve the Promise. isFinished is set first so destroy() doesn't fire onError and queued KVO callbacks bail out; observers are invalidated before the mode mutation so setting .locked can't re-enter the settle tracking.

Android needs no change - it bakes the locking mode into the CameraX FocusMeteringAction via setLockingMode(...) before starting, so the lock is already part of the action when its Promise resolves.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
react-native-vision-camera-docs	Ready	Preview, Comment	Jul 23, 2026 2:48pm

[mrousavy]

Suggested change

	// Update AE/AF/AWB to locked or continuous tracking *before* resolving,
	// so callers observe the final modes as soon as the Promise resolves.
	// Update AE/AF/AWB to locked or continuous tracking to complete the metering task

[mrousavy]

If we add a debug only assert to update() to ensure it is only ever called from the same queue via Dispatch Specific, then we can move these two lines down just above onComplete?() (line 170 now) again to make the code easier to read? not sure if needed 100% tbh, but it felt weird to see isFinished = true, and then some more actual logic (switch adaptivenes { ...}) after that - reads like it isn't finished after all or has an intermediate state then.