App crashes in background after meeting with "length limit exceeded" error

[hyper-charlie]

Description

The app crashes when running in the background, typically right after a meeting ends.

Error Message

UnexpectedStatus { status: 400, body: "length limit exceeded" }

Steps to Reproduce

1. Start a meeting recording in Hyprnote
2. Let the meeting run (unclear if duration matters)
3. End the meeting and close the app or let it run in background

Expected Behavior

The app should process the meeting notes and transcription without crashing.

Actual Behavior

The app crashes with a 400 status error indicating a length limit has been exceeded.

Environment

• Platform: macOS (Apple Silicon)
• OS Version: macOS 15.7.4 Sequoia
• App Version: 1.0.16
• Build: c212379
• Locale: en-CA

Notes

The error suggests a request payload or response body exceeds a limit during post-meeting processing (likely transcription or note generation).

[devin-ai-integration]

Codebase Exploration Findings

Error Origin

The UnexpectedStatus { status: 400, body: "length limit exceeded" } error originates from the owhisper-client crate. The string "length limit exceeded" does not appear anywhere in the codebase — it is returned verbatim by an upstream STT provider's HTTP API response.

Error definition: crates/owhisper-client/src/error.rs:11-15

The error is created when a batch transcription adapter receives a non-success HTTP response:

Err(Error::UnexpectedStatus { status, body: response.text().await.unwrap_or_default() })

Relevant Code Paths

Batch transcription adapters (most likely source — each creates UnexpectedStatus on HTTP 400):

• crates/owhisper-client/src/adapter/deepgram/batch.rs:71
• crates/owhisper-client/src/adapter/openai/batch.rs:138
• crates/owhisper-client/src/adapter/elevenlabs/batch.rs:102
• crates/owhisper-client/src/adapter/fireworks/batch.rs:94
• crates/owhisper-client/src/adapter/gladia/batch.rs:191,239,264
• crates/owhisper-client/src/adapter/mistral/batch.rs:130

Post-meeting processing flow:

• plugins/listener/src/actors/listener/stream.rs:22-77 — finalization loop after session ends
• plugins/listener/src/actors/root.rs:200-227 — stop_session_impl triggers finalization
• crates/transcribe-proxy/src/routes/batch/sync.rs — batch transcription with provider chain & retry

Auto-enhance flow (runs after meeting ends, sends transcript to LLM):

• apps/desktop/src/hooks/useAutoEnhance.ts — triggers on justStopped or batchJustCompleted
• apps/desktop/src/hooks/autoEnhance/runner.ts — calls generateText/streamText via AI SDK

Most Likely Cause

The error occurs because the full meeting audio exceeds the upstream STT provider's file size or duration limit during batch re-transcription after the meeting ends. Common provider limits:

• OpenAI Whisper API: 25 MB file size limit
• Deepgram: Varies by plan
• ElevenLabs: Chunk/session limits

The batch transcription path (crates/transcribe-proxy/src/routes/batch/sync.rs) sends the entire audio file to the provider. For long meetings, this payload can exceed provider limits. The proxy has a 100 MB body limit (routes/mod.rs:162), but individual providers enforce their own stricter limits.

The transcribe proxy does have provider chain fallback (handle_hyprnote_batch) and retry logic with backon, but the retry filter (is_retryable_error in hyprnote_routing.rs:144) treats 400 errors as client errors (non-retryable), so the request fails without fallback to another provider.

Recent Changes

No changes to crates/owhisper-client/, plugins/listener/, or crates/transcribe-proxy/ since the v1.0.16 tag (c212379ec). This suggests it's a pre-existing issue that surfaces with longer meetings.

Potential Approaches

1. Chunked batch transcription: Split long audio files into segments before sending to providers, then stitch results. This would avoid hitting provider payload limits.
2. Provider-aware size validation: Check audio file size/duration against known provider limits before sending, and either chunk or select an appropriate provider.
3. Improve fallback behavior: The is_retryable_error function in hyprnote_routing.rs:144 classifies 400 as non-retryable. For "length limit exceeded" specifically, falling back to a different provider (one with higher limits) could help.
4. Better error surfacing: Currently the error causes a crash. Catching it gracefully and showing a user-facing message (e.g., "Meeting too long for cloud transcription, try local STT") would improve UX.

What Would Help

• Logs from the transcribe-proxy showing which provider was used and the body_size_bytes logged at batch/sync.rs:63 and batch/mod.rs:68
• Meeting duration — knowing how long the meeting was would help identify the threshold
• Which STT provider the user is configured to use (cloud vs local, which cloud provider)