Several paths through the AVFoundation pull loop could end a compression
with no result at all — no success, no failure, no crash — leaving the
caller waiting forever:
- The terminal branches did not return, so the loop could re-enter, find
the audio reader already reading, take the no-audio branch and call
finishWriting while the audio input was still unfinished. A writer in
that state never completes. - A failed reader returned quietly through a bare guard.
- The audio loop had the same missing return, so a second
markAsFinished/finishWriting was reachable. - The audio phase began with a redundant second startSession.
- The audio phase never checked for cancellation.
Every terminal path now returns, a failed reader reports a failure, and
the terminal reply and finishWriting each run exactly once behind
single-shot guards. These are latent defects found by inspection: a
physical iPhone 13 Pro Max (iOS 26.5.2) and macOS 15.7 both complete 4K
camera clips in either audio mode, and native probes show each terminal
branch running exactly once.
Also closes a coverage gap: the bundled sample clip has no audio track,
so the Apple audio mux (passthrough and AAC re-encode) was never
exercised — which is how the addInput crash fixed in 1.9.0 reached a
release. Adds an audio-bearing fixture, generated with the plugin's own
pipeline, and real coverage for both paths. Verified by reverting that
fix on a physical device: the new test crashes the app and passes with
the fix, where the previous one passed either way.
Bumps to 1.9.1.