Live transcription stops after 3 minutes with error, but audio continues recording

[hyper-charlie]

Issue Summary

Live transcription stops unexpectedly after ~3 minutes into a 60-minute Google Meet recording. Audio continues recording in the background, but transcription halts with an error message: "Live transcription had stopped". Manual summary trigger only summarizes the portion that was transcribed before the cutout.

Steps to Reproduce

1. Start a Google Meet recording in Hyprnote (using cloud-based transcription model)
2. Allow meeting to progress
3. After ~3 minutes, experience connectivity issues causing live transcription to stop with error: "Live transcription had stopped"
4. Confirm audio is still being captured in the background
5. Manually trigger summary when meeting ends
6. Summary only includes content from the first ~3 minutes

Expected Behavior

If live transcription stops (e.g., due to connectivity issues) but audio is still being recorded:

• The recorded audio should be automatically stored
• The stored audio should be used to create a new transcription post-meeting
• The summary should include all recorded audio, not just the portion transcribed before the cutout

Actual Behavior

• Transcription stops after 3 minutes with "Live transcription had stopped" error
• Audio recording continues uninterrupted
• Manual summary only includes pre-cutout content
• Recorded audio after transcription stopped is lost from summary

Environment

• Platform: macOS (aarch64)
• OS Version: macOS 26.3.1
• App Version: 1.0.17
• Build: 866a098
• Locale: en-GB
• Meeting Type: Google Meet
• Transcription Model: Cloud-based (WiFi-dependent)

Additional Notes

• First occurrence; suspected to be WiFi/connectivity-related since cloud models were in use
• No system resource constraints observed
• The discrepancy between recording continuing and transcription stopping suggests a cloud service/encoder connectivity issue rather than a local recording failure
• Users relying on cloud transcription models are vulnerable to this experience if WiFi connectivity drops

[devin-ai-integration]

Codebase Analysis

Relevant Files & Components

Core issue path: WebSocket disconnection → ListenerActor stops → supervisor exhausts restarts → entire session tears down, but audio was being recorded to disk up until teardown

Listener Plugin (audio capture + transcription orchestration)

• plugins/listener/src/actors/session.rs — Session supervisor using RestForOne strategy with max_restarts: 3 within a 15-second window (make_supervisor_options()). The ListenerActor has a 500ms backoff on restart (make_listener_backoff()). Child spec order: SourceActor → ListenerActor → RecorderActor.
• plugins/listener/src/actors/listener/mod.rs — ListenerActor handles StreamError, StreamEnded, and StreamTimeout by calling myself.stop(None). For StreamResponse::ErrorResponse, it emits SessionErrorEvent::ConnectionError and stops. There is no reconnection logic within the actor — it relies on the supervisor restart strategy.
• plugins/listener/src/actors/listener/stream.rs — process_stream() loop: any WebSocket error breaks the loop and sends ListenerMsg::StreamError, causing the actor to stop. The stream timeout is 15 minutes (LISTEN_STREAM_TIMEOUT).
• plugins/listener/src/actors/listener/adapters.rs — Connection setup with a 5-second connect timeout (LISTEN_CONNECT_TIMEOUT). No retry at this level.
• plugins/listener/src/actors/recorder.rs — RecorderActor writes WAV audio continuously. Uses Restart::Transient in the child specs. Its post_stop properly finalizes/flushes the WAV file to {vault}/sessions/{session_id}/audio.wav.
• plugins/listener/src/actors/root.rs — RootActor detects supervisor termination/failure and emits SessionLifecycleEvent::Inactive with the failure reason. stop_session_impl explicitly stops RecorderActor first to ensure post_stop flushes audio.

WebSocket Client

• crates/ws-client/src/client.rs — Initial connection has retry logic (3 attempts, 500ms delay via backon), but once connected, there is no reconnection on mid-stream disconnection. A Message::Close or receiver error breaks the output stream. Keep-alive pings are sent every 5 seconds, and a failed keep-alive also breaks the stream.

Frontend

• apps/desktop/src/store/zustand/listener/general.ts:258-278 — handleErrorEvent stores connection_error in lastError. The handleLifecycleEvent for inactive stores payload.error in lastError and resets transcript state.
• apps/desktop/src/components/main/body/sessions/shared.tsx:101-102 — Displays error as "Session failed: ${lastError}" (this is what the user sees as "Live transcription had stopped").

Batch Transcription (existing infrastructure)

• plugins/listener2/src/ext.rs — run_batch() can process a WAV file post-hoc using cloud STT providers (Deepgram, Soniox, AssemblyAI, AM).
• apps/desktop/src/hooks/useRunBatch.ts — Frontend hook that creates a new transcript and triggers batch transcription on a given audio file path.

Root Cause Analysis

The architecture has a gap between recording resilience and transcription resilience:

1. Recording is partially resilient: SourceActor captures audio → sends to both ListenerActor (for live STT) and RecorderActor (for WAV writing). Audio is written to disk as long as the session is alive.

2. Transcription is not resilient to sustained disconnection: When WiFi drops:

   • WebSocket connection fails → StreamError → ListenerActor.stop()
   • Supervisor restarts ListenerActor (up to 3 times in 15s via RestForOne)
   • If WiFi is still down, all 3 retries fail → supervisor exhausts max_restarts
   • RestForOne strategy tears down the entire session including RecorderActor and SourceActor
   • RootActor emits Inactive with error → frontend shows "Session failed: ..."

3. Audio recording stops when session tears down: Because the supervisor strategy couples all actors together, when ListenerActor exhausts restarts, RecorderActor is also stopped. The WAV file IS properly finalized (flushed in post_stop), but it only contains audio up to the point of session teardown — not the full meeting.

4. No automatic fallback: The batch transcription system exists but there is no automatic trigger to re-transcribe the saved audio when live transcription fails. The user must manually initiate it, and the UI doesn't surface this option after a failure.

5. Summary only uses live transcript data: When the user triggers a summary, it operates on transcript words in TinyBase — only what was received before the WS disconnection (~3 minutes).

Key Architectural Observations

• The RestForOne supervisor strategy in session.rs:43 is the critical coupling point. Child order is Source → Listener → Recorder, so when Listener fails permanently, RestForOne stops everything after it (Recorder) and the supervisor itself terminates.
• The 3-restart / 15-second window (max_restarts: 3, max_window: Duration::from_secs(15)) is tight for WiFi recovery — a dropout lasting >15s would exhaust all retries.
• The WS client's backon retry only covers initial connection, not mid-stream reconnection.

Potential Approaches

1. Decouple recorder from transcription failures: Restructure the supervisor so RecorderActor + SourceActor survive ListenerActor exhaustion. For example, use separate supervisor groups or change to OneForOne strategy with the recorder in its own supervisor.

2. Auto-trigger batch re-transcription on failure: When a session ends with an error but has a saved WAV file, automatically queue listener2::run_batch on the recorded audio. The infrastructure already exists in plugins/listener2/.

3. Increase resilience window: Bump max_restarts or max_window in make_supervisor_options(), or use exponential backoff in make_listener_backoff() to survive longer connectivity gaps.

4. Add mid-stream WS reconnection: In crates/ws-client/src/client.rs, implement reconnection when the stream drops mid-session rather than terminating.

5. Improve failure UX: When SessionLifecycleEvent::Inactive fires with an error and a WAV file exists at the session path, prompt the user to re-transcribe via batch processing. The useRunBatch hook already supports this workflow.