zeroclaw-labs/zeroclaw · error

AssemblyAI transcription timed out after 180s

Error message

AssemblyAI transcription timed out after 180s

What it means

The AssemblyAI poll loop ran for 180 seconds without the job reaching "completed" or "error", so the provider gave up. The 180-second ceiling is hardcoded in the provider, not configurable. The job may still be running (or even complete) on AssemblyAI's side — only the local wait was abandoned.

Source

Thrown at crates/zeroclaw-channels/src/transcription.rs:596

            match status_str {
                "completed" => {
                    let text = poll_body["text"]
                        .as_str()
                        .context("AssemblyAI response missing 'text'")?
                        .to_string();
                    return Ok(text);
                }
                "error" => {
                    let error_msg = poll_body["error"]
                        .as_str()
                        .unwrap_or("unknown transcription error");
                    bail!("AssemblyAI transcription failed: {}", error_msg);
                }
                _ => {}
            }
        }

        bail!("AssemblyAI transcription timed out after 180s")
    }
}

// ── GoogleSttProvider ───────────────────────────────────────────

/// Google Cloud Speech-to-Text API transcription_provider.
pub struct GoogleSttProvider {
    alias: String,
    api_key: String,
    language_code: String,
}

impl GoogleSttProvider {
    pub fn from_config(
        alias: &str,
        config: &zeroclaw_config::schema::GoogleSttConfig,
    ) -> Result<Self> {
        let api_key = config

View on GitHub (pinned to 88bb9c8533)

Solutions

1. Retry the transcription — short files normally finish well under 180 s, and a retry after a transient backlog usually succeeds
2. Split long audio into chunks under ~10 minutes each before transcribing
3. Check status.assemblyai.com and the dashboard queue if timeouts repeat
4. For consistently long jobs, switch the agent's transcription_provider to a streaming/synchronous provider (Groq, OpenAI, Deepgram) which returns in one request

Example fix

# split a long recording into 10-minute chunks before transcription
ffmpeg -i meeting.wav -f segment -segment_time 600 -c copy chunk_%03d.wav

match provider.transcribe(&audio, name).await {
    Ok(text) => Ok(text),
    Err(e) if e.to_string().contains("timed out after 180s") => {
        // job may still complete server-side; one bounded retry is cheap for short files
        retry_once(|| provider.transcribe(&audio, name)).await
    }
    other => other,
}

When it happens

Trigger: AssemblyAI queue latency or a very long audio file keeps the transcript in "processing"/"queued" for over 180 s; the poll loop exhausts its deadline and bails. Typical for 30+ minute recordings or during AssemblyAI incidents/peak load.

Common situations: Transcribing long meetings/calls through AssemblyAI; free-tier accounts with slow queue priority; retrying immediately after a timeout while AssemblyAI is still backlogged.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• AssemblyAI poll error ({}): {}
• AssemblyAI upload error ({}): {}
• AssemblyAI transcription error ({}): {}
• AssemblyAI transcription failed: {}
• ACP elicitation/create timed out after {timeout:?}

AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/6ad344b0c9d7b836. Report an issue: GitHub.