[Bug]: iPhone voice input says a transcription is already active after leaving a thread mid-dictation instead of cancelling it #13743

Activity

1. juliusmarminge commented on Sep 26, 2026

   

   juliusmarminge

   on Sep 26, 2026

   Member

   More actions

   Triage

   Confirmed on current main (ecd3237b18). This is a real iPhone dictation bug. Not already fixed. The session lock landed with offline voice input in #8614 and has not changed since. Installed 1.2.1 already has it. 88d0c40c85 is the 1.2.1 bump; 76cc9b08f1 is the later 1.3.0 bump, not 1.2.1. Nothing between 1.2.1 and main changes this lock. #12227 only keeps the screen awake, and #12534 only touches theme colors. Updating the app will not change this.

   No open issue covers it. #10140 describes the same error and is not the fix. That PR keeps the original recording alive across threads and still rejects a second one. This report is the opposite: the abandoned session should get out of the way.

   What you hit

   On iPhone, picking another thread pushes a new Thread screen. The one you left blurs, and useFocusEffect calls dispose(). The composer goes idle. The next microphone tap is a different VoiceInputController, but both share two module globals in packages/client-runtime/src/voice-input/controller.ts:

   let activeSession: symbol | null = null;
   let activeTranscriptionOperation: Promise<unknown> | null = null;
   
   function acquireSession(): symbol | null {
     if (activeSession) return null;
     // ...
   }
   
   async function runTranscriptionOperation<T>(operation: () => Promise<T>): Promise<T> {
     if (activeTranscriptionOperation) {
       throw new Error("voice-operation-busy");
     }
     // ...
   }

   cancel(), dispose(), and ownerChanged() only bump the operation token, abort the signal, and set idle. releaseSession() runs later, inside releaseResources(), from the finally of start() or finishRecording(). That finally waits until the native call returns.

   AppleTranscription.prepare() and .transcribe() cannot be interrupted. apps/mobile/src/native/voiceTranscription.ios.ts checks the signal only before and after those awaits. An abandoned prepare or transcribe holds activeSession until the native call settles. The new start() then fails here:

       const sessionToken = acquireSession();
       if (!sessionToken) {
         this.setError("Another voice recording is already active.", "retry");
         return;
       }

   That is the message this navigation path shows. "Voice transcription is still finishing" comes from voice-operation-busy, and this path does not reach it, because the session lock is still held for the whole native call. Dismissing the error only clears local state. It does not release the other controller’s lock.

   Leaving during recording is a short window: discardRecording() holds the lock until recorder.stop() and audio cleanup finish. The long block is preparing and transcribing. The lock does release when that call finishes, which matches waiting a few seconds. A permanent stuck state is not what this code does unless the native call never returns. Backgrounding during transcribing does not cancel it. appMovedToBackground() only handles preparing and recording.

   This rejection is the current contract, not an accident. controller.test.ts expects the next controller to see "already active" after cancel, dispose, and ownerChanged until a non-abortable transcription settles, and the same for a cancelled prepare. Changing the behavior means changing those tests.

   iPad split view is the same lock through ownerChanged() on one composer. Android does not use this transcriber.

   Direction

   Queue a start that follows an abandoned session. Do not show an error for a session the user already left. Keep one Apple call at a time. Do not overlap prepare or transcribe, and do not pretend the signal stops them.

   Releasing the session token immediately, while the old finally still runs releaseRecording(), is unsafe. That callback is process-wide (setAudioModeAsync({ allowsRecording: false }) and setIsAudioActiveAsync(false)). A late cleanup from the abandoned controller will tear down the new recording. The next start() has to wait until the abandoned controller has finished native work and audio cleanup, then proceed, showing Preparing rather than an error.

   If the owner is still actively preparing, recording, or transcribing and has not been cancelled or disposed, keep the single-session rejection.

   Constraints for a PR:

   • Only mobile voice input. Web does not use this controller.
   • An abandoned session must not leave the next microphone tap on "Another voice recording is already active."
   • A second native Apple call must not start until the abandoned one and its audio cleanup have finished.
   • A still-active, not-abandoned recording must still reject a second start.
   • Replace the two controller.test.ts cases that expect "already active" after cancel, dispose, owner change, and cancelled prepare. Add the case the report describes: controller A is in transcribing or preparing with a never-resolving native call, A is cancelled or disposed, then B start() reaches recording only after that call settles, with no error.
   • Do not take feat(mobile): keep voice recording active across apps and threads #10140’s background-audio or keep-recording behavior as part of this fix.

   Workaround. Wait until the abandoned transcription finishes, then tap the microphone again. Force-quitting the app clears the lock immediately because it lives in the JS heap. Backgrounding alone does not.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 26, 2026
3. cursor

   added 2 commits that reference this issue on Sep 27, 2026

   fix(mobile): start voice on a new thread after cancel

   ...

   This issue will close once commit e145716 is merged into the 'main' branch.

   e145716

   docs(client-runtime): document voice session lock helpers

   ...

   This issue will close once commit 57edbfb is merged into the 'main' branch.

   57edbfb
4. juliusmarminge

   closed this as completedin #15502on Oct 4, 2026