fix(react-native): deliver Whisper transcripts after stop

[StiensWout]

Stopping the React Native Whisper transcriber discards the final buffered transcript and any decode still running. Queue decodes in audio order and deliver results for audio accepted before stop, while continuing to ignore later audio and repeated stop calls.

Related to #13011. This fixes the React Native adapter only; the shared cross-language lifecycle discussion remains open.

Validation:

• Five hardware-independent tests exercise the exported transcriber with synthetic PCM and injected runners. The tail and in-flight tests fail on unchanged upstream and pass with the fix. A delayed first batch reproduces the ordering issue before serialization and passes after it. The queue also continues after a failed earlier batch.
• The tests run through the shared local/CI check manifest using the existing Bun runtime.
• No physical device or live model was used.

Failure-Class: none

Product invariants affected: none.

[cubic-dev-ai]

All reported issues were addressed across 4 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[Git-on-my-level]

Verified this end to end in an isolated offline container using the repo's pinned Bun (1.3.14):

• sdks/react-native/src/stt/whisper.ts: the merge-base flush() only delivered when !stopped, so stop() discarded both the buffered final tail and any in-flight decode result. With this change all accepted audio is delivered: the tail is flushed, decodes still running at stop() deliver when they settle, and chaining on a single pending promise keeps batches strictly in audio order. I confirmed true serialization with a probe - the second batch's runner is not invoked until the first batch's decode resolves - which also resolves the earlier inline review's out-of-order concern. The added if (stopped) return guard makes repeated stop() calls deliver the tail exactly once.
• sdks/react-native/tests/whisper.test.mjs: the five tests pass on this head and four of them fail on the merge-base implementation, so they genuinely discriminate the fix rather than restating it. Hardware-independent with injected runners, matching the device-SDK test style.
• .github/checks-manifest.yaml: the react-native-whisper-tests entry follows the existing shape (id/command/triggers/lanes/reason), and the ci hygiene lane already sets up Bun 1.3.14 via oven-sh/setup-bun, so the check is runnable as declared.
• docs/doc/developer/sdk/ReactNative.mdx: each documented claim (tail flush at stop, post-stop delivery of in-flight decodes, sequential order, idempotent stop, the bun test invocation) matches the behavior I observed.

One non-blocking observation: a rejected runner is now swallowed silently by the pending.then(decode, decode) chain (previously it surfaced as an unhandled rejection), which keeps later accepted audio decoding - the right trade-off here since StreamingTranscriber exposes no error channel. If whisper.rn decode failures ever matter to SDK consumers, an optional error callback would be a natural follow-up.

Note: no checks have reported on this head yet - workflow runs for a first-time contributor typically need a maintainer's approval before they start. Leaving the merge decision to a human maintainer; the fix itself looks correct and is nicely tested.

This feedback is AI-generated on behalf of the Omi maintainers.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[kodjima33]

fix(react-native): deliver Whisper transcripts after stop. Confidence ~4/5 (title fix(), root cause stated, small scoped diff, regression tests added). Confirmed bug still present on main (stop() sets stopped=true before flush()'s onTranscript call, discarding the final transcript).