Transcription stops unexpectedly mid-call while Zoom meeting is still active

[hyper-charlie]

Issue

Hyprnote transcription randomly stops in the middle of active Zoom calls, even though the meeting is still ongoing. No error message is displayed.

Details

• Frequency: Random/intermittent (happens regularly but unpredictably)
• Call duration: Happens regardless of call length (short or long calls)
• Microphone setup: Occurs with both AirPods and macOS built-in mic
• Error message: None visible
• User environment: macOS 26.3, App 1.0.10

Steps to Reproduce

1. Start a Zoom meeting
2. Start transcription in Hyprnote
3. Transcription stops at random point while Zoom call is still active

Expected Behavior

Transcription should continue until the user manually stops it or the Zoom call ends.

Actual Behavior

Transcription stops unexpectedly, requiring user to restart transcription.

Environment

• Platform: macOS (aarch64)
• App version: 1.0.10
• Build: 58a816d
• Locale: en-US

[devin-ai-integration]

Codebase Exploration — Transcription Stops Mid-Call

I explored the codebase to understand the possible causes for transcription stopping unexpectedly. Here's what I found:

Relevant Files & Components

The transcription session is managed by an actor-based architecture (using ractor) with a supervision tree:

Actor	File	Role
RootActor	plugins/listener/src/actors/root.rs	Top-level session manager; handles lifecycle events, supervision
SourceActor	plugins/listener/src/actors/source/mod.rs	Audio capture (mic + speaker); device monitoring
ListenerActor	plugins/listener/src/actors/listener/mod.rs	WebSocket STT connection; processes stream responses
RecorderActor	plugins/listener/src/actors/recorder.rs	WAV file recording
Session Supervisor	plugins/listener/src/actors/session.rs	Supervises all child actors with RestForOne strategy

Audio flows: SourceActor → Pipeline (source/pipeline.rs) → ListenerActor → STT provider (via WebSocket in ws-client/src/client.rs) → StreamResponse events to frontend.

Frontend state management: apps/desktop/src/store/zustand/listener/general.ts

Potential Causes (Ordered by Likelihood)

1. WebSocket Stream Ending or Erroring Silently

In plugins/listener/src/actors/listener/stream.rs:79-101, the stream loop has a 15-minute timeout (LISTEN_STREAM_TIMEOUT). If the STT provider closes the WebSocket or the connection drops:

• StreamEnded → actor stops silently (line 219-222 in listener/mod.rs)
• StreamError → actor stops silently (line 214-217)
• StreamTimeout → actor stops after 15 min inactivity (line 224-227)

All three cases call myself.stop(None) which does not propagate an error message to the user. The supervisor will attempt a restart (up to 3 times in 15s), but if the underlying issue persists, the session terminates.

In ws-client/src/client.rs:188-195, a ResetWithoutClosingHandshake error is silently downgraded to debug level, meaning the connection could drop without any visible error.

2. Audio Device Change During Zoom Call

SourceActor spawns a DeviceChangeWatcher (source/mod.rs:59-88) that monitors for DefaultInputChanged events. When the default input device changes (e.g., Zoom switching audio routing, AirPods reconnecting, macOS audio system changes), the SourceActor is stopped with reason "device_change" (line 81). This triggers a RestForOne restart of both SourceActor and ListenerActor.

If restarts exceed max_restarts: 3 within max_window: 15s (configured in session.rs:41-48), the entire session supervisor terminates, ending the transcription with no user-visible error.

3. Audio Stream Failure

In source/stream.rs, if the mic or speaker stream encounters an error or ends unexpectedly:

• mic_stream_ended / speaker_stream_ended (lines 218-224, 251-257) → reports fatal AudioError and stops the actor
• mic_resample_failed / speaker_resample_failed → same fatal path

The speaker capture on macOS (crates/audio/src/speaker/macos.rs) uses a ring buffer. If samples are dropped (dropped_samples counter), audio data is lost but the stream continues. However, the SpeakerStream doesn't have explicit reconnection logic — if the CoreAudio aggregate device/tap fails, the stream would end.

4. STT Provider Error Response

In listener/mod.rs:165-192, if the provider returns an ErrorResponse, the actor stops itself and emits a ConnectionError event. The supervisor may restart it, but repeated errors would exhaust the restart budget.

Recent Related Changes

• a8fdf03 — Fixed a keepalive race condition in ws-client where the send loop could continue after finalize, potentially causing connection issues
• bf9c7b8 — Fixed mic stream data accumulation and added bounded channels to ws-utils, addressing potential memory/backpressure issues
• f9cbbb2 → 92133f0 — Adjusted supervisor restart limits from max_restarts: 2 / max_window: 10s to 3 / 15s, and toggled connect timeout between 3s and 5s — suggesting this class of issue has been investigated before

Key Observations

1. No user-visible error: When the session ends due to actor failure or stream termination, the frontend receives a SessionLifecycleEvent::Inactive with an optional error field (root.rs:108,121). However, in many failure paths, myself.stop(None) is called without an error string, so lastError on the frontend stays null.

2. Supervisor restart budget is tight: 3 restarts in 15 seconds means rapid device switches (common with Zoom + AirPods) can exhaust the budget quickly and silently kill the session.

3. No automatic session recovery: Once the supervisor terminates, there's no mechanism to automatically restart the session. The user must manually restart.

Suggestions for Investigation

1. Add Sentry breadcrumbs or structured logging for StreamEnded, StreamError, StreamTimeout, and device change events so we can correlate with user reports
2. Always pass error reasons when stopping actors — change myself.stop(None) to myself.stop(Some("stream_ended")) etc., so the frontend can surface what happened
3. Consider increasing the supervisor restart budget or adding exponential backoff for transient failures (device changes, brief network blips)
4. Add a reconnection mechanism at the session level — when Inactive is received unexpectedly (no user-initiated stop), offer to auto-resume
5. Check if the user's STT provider has connection limits or idle timeouts that could explain the WebSocket closing

Additional Info That Would Help

• Which STT provider is the user using? (Deepgram, Argmax, local Whisper, etc.)
• Are there any entries in Sentry around the time transcription stops?
• Does the macOS Console show any CoreAudio-related messages when this happens?

[hyper-charlie]

Additional report: Teams call, stream ended mid-recording

• Platform: macOS (aarch64, v26.3)
• App: 1.0.11 (build 0b5cb58)
• Call platform: Microsoft Teams
• Call duration before drop: ~10 minutes
• Symptom: Transcription tab shows "stream ended" message; only first part of conversation was transcribed
• Call status: Teams call remained active, no disconnection or audio/video issues
• Network: No connectivity issues observed
• Frequency: First occurrence of this specific issue; user previously experienced complete recording failures but not mid-call drops

The drop occurred immediately after updating to the latest version (1.0.11).

Steps to reproduce would require another Teams call, but the failure happened without any user action—audio was flowing normally when the stream ended.

[dandaka]

same here #3926

[hyper-charlie]

Additional report:

User experiencing intermittent STT dropouts on cloud providers (Pro plan / Mistral).

Details:

• Occurs randomly, mainly in first 10 minutes
• Once stops, transcript never catches up (recording continues)
• Jabra headset connected
• App restarted multiple times—issue persists
• macOS (aarch64, v26.3)
• App v1.0.11

Cloud STT providers affected: Pro plan STT, Mistral

[hyper-charlie]

Log collection request:

User is willing to provide logs from a reproduction session. What's the best way to share them? (e.g., app diagnostic export, direct log file location, or support email)