Live transcription stops mid-call + Regenerate can't recover the missing portion (Deepgram, 2h call)

[dandaka]

Summary

Two bugs compounded on a real 2-hour call today, leaving me with only 11 minutes of transcript for a 2-hour recording and no way to recover it:

1. Live transcription stopped partway through the call while the recording continued uninterrupted. The UI showed the "Live transcription stopped. Transcript will be created after you stop." error. Nothing in my environment changed — I was just sitting on the call.
2. After the call ended, the "Regenerate transcript" button does not actually re-transcribe. It shows progress, but the end result is identical — still only 11 minutes of transcript for a 2-hour WAV. Switching transcription models before hitting Regenerate produced the same unchanged result.

This combination makes the bug much more painful than either issue alone — the full audio was captured on disk but there's no working path to a full transcript.

Steps to Reproduce

1. Start a long call (2h in my case) with Deepgram as the cloud transcription provider.
2. At some point mid-call, live transcription stops with: "Live transcription stopped. Transcript will be created after you stop."
3. Recording continues for the rest of the call without any user action.
4. End the call.
5. Observe that the saved transcript only covers the first ~11 minutes (up to the WebSocket drop), while the audio file is the full 2 hours.
6. Click "Regenerate transcript". Optionally switch to a different model first.
7. Progress indicator runs, but the final transcript is still ~11 minutes. No new content, no errors surfaced.

Expected Behavior

• Either live transcription auto-recovers after a transient disconnect, or
• Regenerate transcript runs a fresh batch transcription over the entire saved WAV using the currently selected model / API key and replaces the old partial transcript with a complete one.

Actual Behavior

• Live transcription dies mid-call and never resumes, even though the session is still alive and recording.
• Regenerate transcript visibly runs but produces no change to the transcript length or content — regardless of which model is selected.
• There is no working user-facing path to get a transcript for the portion of audio captured after the WebSocket drop.

Environment

• App: Char
• App Version: 1.0.24
• Platform: macOS (Apple Silicon)
• Transcription Provider: Deepgram (own API key)
• Call length: ~2 hours
• Resulting transcript length: ~11 minutes
• Audio recording on disk: full 2 hours

Related Issues

• Live transcription stops after 3 minutes with error, but audio continues recording #4707 — Live transcription stops after 3 minutes with error, but audio continues recording. Same mid-call drop pattern; my case happened later into the call but produced the same "Live transcription stopped" state with audio still recording. The existing Devin analysis on that issue traces the root cause to the RestForOne supervisor tearing down on WS exhaustion and no auto-trigger for batch re-transcription on the saved WAV.
• Regenerate transcript button doesn't re-transcribe with connected API key #5004 — Regenerate transcript button doesn't re-transcribe with connected API key. Same regenerate-is-a-no-op behavior, but that report is about re-transcribing a complete recording for quality. My case shows Regenerate also fails to extend a truncated transcript — arguably a worse failure mode because the data for the full transcript simply never gets produced.

Why This Warrants a Separate Issue

The two existing issues describe the component failures. This report documents the combined user impact: a user who hits #4707 cannot use the mechanism (#5004) that would otherwise be their recovery path. In practice that means data loss for long meetings, even though the raw audio was successfully captured. Closing both issues independently is necessary but not sufficient — the recovery flow (live failure → batch re-transcribe full WAV) needs to work end-to-end.

Suggested Priorities

1. Make "Regenerate transcript" actually run batch transcription over the full WAV with the selected provider and replace the stored transcript. This is the recovery path users reach for.
2. Auto-trigger batch re-transcription on SessionLifecycleEvent::Inactive when a WAV exists and the stored transcript is shorter than the audio duration — so users don't have to know to click Regenerate.
3. Address the underlying mid-stream WS reconnection gap (already discussed in Live transcription stops after 3 minutes with error, but audio continues recording #4707).

[dandaka]

Bug repeats