WebSocket error when recreating transcript for long audio files (71+ mins)

[hyper-charlie]

Description

Cannot recreate transcript for a 71-minute audio MP3 file. When pressing the redo icon on the transcript tab, the app fails with a WebSocket message-too-large error.

Steps to Reproduce

1. Have a 71-minute audio MP3 file
2. Navigate to the transcript tab
3. Press the redo icon to recreate the transcript
4. The app attempts to analyze the audio

Expected Behavior

The transcript should be successfully recreated from the long-form audio file.

Actual Behavior

WebSocket connection closes with error: RemoteClosed(code=Some(1009), reason="")

• Code 1009 indicates the message is too large for the WebSocket endpoint

Environment

• Platform: macOS
• Architecture: aarch64
• OS Version: macOS 26.4
• App Version: 1.0.17
• Build: 866a098
• Audio Duration: ~71 minutes

Root Cause

The WebSocket payload for transcript recreation likely exceeds the configured message size limit when handling long-form audio content.

Notes

This appears to be a limitation with how transcript recreation requests are serialized over WebSocket. Consider either:

• Increasing WebSocket message size limits
• Chunking the transcript recreation for long audio files
• Using an alternative protocol for large payloads

[devin-ai-integration]

Codebase Exploration: WebSocket 1009 on Long Audio Batch Transcription

Transcript Recreation Flow

The redo button triggers this path:

1. UI: apps/desktop/src/session/components/note-input/header.tsx (handleRefreshClick → runBatch(audioPath))
2. Hook: apps/desktop/src/stt/useRunBatch.ts — builds BatchParams with provider from STT connection config
3. Plugin dispatch: crates/listener2-core/src/batch/mod.rs (run_batch_inner) — routes based on BatchProvider:
   • Am | Cactus → run_batch_streaming (WebSocket streaming) ← likely path for this error
   • All others (Deepgram, OpenAI, Hyprnote, etc.) → run_batch_simple (HTTP POST, no WebSocket)
4. Streaming batch: crates/listener2-core/src/batch/bootstrap.rs → spawn_batch_task → dispatches to adapter-specific streaming (Argmax, Cactus, or generic spawn_batch_task_with_adapter)
5. WebSocket client: crates/ws-client/src/client.rs (from_audio) — sends audio chunks and receives transcript responses
6. WebSocket connection: crates/ws-client/src/retry.rs (connect_with_retry → connect_async)

Key Finding: No Explicit WebSocket Message Size Configuration

The codebase uses tokio_tungstenite::connect_async without a custom WebSocketConfig (no max_message_size / max_frame_size set). The axum WebSocketUpgrade in the proxy also has no message size configuration. This means tungstenite defaults apply (64MB max message, 16MB max frame) on the client side.

The 1009 error is from the remote/upstream side — RemoteClosed(code=Some(1009)) means the server the client connects to rejected a message as too large. This points to the upstream STT server (local Argmax/Cactus or transcribe-proxy) having its own message size limit.

Audio Chunking Strategy

• DEFAULT_CHUNK_MS = 500 and DEFAULT_DELAY_MS = 20 (in bootstrap.rs)
• For 16kHz mono 16-bit audio: each 500ms chunk ≈ 16KB
• 71-minute file → ~8,520 chunks — each individually small

Individual audio chunks should not trigger size limits. The issue is more likely in the response direction: the upstream STT server accumulating transcript data for 71 minutes and sending back a response message that exceeds its own outbound WebSocket frame/message limit.

Relevant Files

File	Role
crates/listener2-core/src/batch/mod.rs	Batch dispatch (streaming vs HTTP)
crates/listener2-core/src/batch/bootstrap.rs	Audio chunking, WebSocket stream setup
crates/owhisper-client/src/adapter/argmax/batch.rs	Argmax streaming batch (transcribe_file_streaming)
crates/ws-client/src/client.rs	WebSocket client (send/receive loop)
crates/ws-client/src/retry.rs	WebSocket connection (no custom config)
crates/ws-client/src/error.rs	RemoteClosed error type
crates/transcribe-proxy/src/relay/handler.rs	Proxy relay (no message size config)
apps/desktop/src/stt/useRunBatch.ts	Frontend batch orchestration

Recent Relevant Commits

• afd405fd2 — handle backpressure in ws-utils (changed try_send → send for audio channels)
• 6ac06c35e — Improve ws-client retry/error handling (major refactor of ws-client)
• 601eeea83 — various batch transcription and observability fixes
• cbf94bc6e — various batch processing bugfixes
• 985f63f9b — forward_dual_to_single backpressure

Potential Investigation Directions

1. Identify which STT provider the user is using — the WebSocket streaming batch path only applies to Am/Cactus providers; other providers use HTTP POST. If the user is on Hyprnote cloud routing, this goes through the transcribe-proxy which then connects to an upstream provider's WebSocket.

2. Check upstream STT server message size limits — the Argmax sidecar or Cactus server may have its own WebSocket frame/message size limits that get exceeded when sending back accumulated transcript responses for long audio.

3. Check the transcribe-proxy's upstream connection — if going through the proxy, tokio_tungstenite::connect_async on the proxy → upstream connection also uses default config. The upstream provider (e.g., Deepgram) may enforce its own limits.

4. Response accumulation — for long audio, the STT server may accumulate a large final transcript response. Consider whether the Finalize response from the upstream is what triggers the 1009.