What causes "Deepgram transcription failed - ${error.message}" in Mintplex-Labs/anything-llm?

Check for a nested '(status) - body' suffix — if present, treat it as the API-status case (fix key/model per that status) rather than a network fault

Mintplex-Labs/anything-llm · error · Error

Deepgram transcription failed

Error message

Deepgram transcription failed - ${error.message}

What it means

This is the .catch at the end of the Deepgram fetch chain: any error thrown earlier — network failures (DNS, ECONNREFUSED, TLS), body-read/JSON-parse failures, or the non-ok status error itself — is logged and re-thrown wrapped in this generic prefix. Because the inner status error passes through the same catch, its message text is duplicated inside this one.

Solutions

Check for a nested '(status) - body' suffix — if present, treat it as the API-status case (fix key/model per that status) rather than a network fault
Verify outbound connectivity: curl -H 'Authorization: Token <key>' 'https://api.deepgram.com/v1/listen' from the same host/container
Configure proxy/TLS env (HTTPS_PROXY, NODE_EXTRA_CA_CERTS) when a corporate network intercepts traffic
Add a retry with backoff for transient network failures before surfacing the error

Defensive patterns

Strategy: retry

Validate before calling

// Fail fast on obvious connectivity problems before calling Deepgram
await fetch('https://api.deepgram.com/v1/listen', { method: 'HEAD' }).catch(() => {
  throw new Error('api.deepgram.com is unreachable from this host');
});

Try / catch

let lastErr;
for (let attempt = 0; attempt < 3; attempt++) {
  try { return await stt.process(audioBuffer, filename); }
  catch (err) {
    lastErr = err;
    if (/\((4|5)\d\d\)/.test(err.message)) throw err; // wrapped API-status error: not a network fault
    await sleep(2 ** attempt * 500); // DNS/ECONNREFUSED/TLS: retry with backoff
  }
}
throw lastErr;

Prevention

Distinguish nested status errors from network faults by checking for the '(status)' pattern before retrying
Configure proxy and CA env vars (HTTPS_PROXY, NODE_EXTRA_CA_CERTS) in restricted networks
Add a request timeout so hung connections fail into the catch quickly

When it happens

Trigger: fetch cannot reach api.deepgram.com (offline, DNS failure, firewall/proxy blocking, TLS interception); response.text()/json() throws on a malformed body; or a wrapped re-throw of the HTTP-status error from the previous stage, recognizable by the '(status) - body' suffix inside the message.

Common situations: Self-hosted/Docker deployments without outbound internet; corporate proxies requiring custom CA or HTTP_PROXY settings; transient network blips mid-upload; reading the message without realizing it nests the original status error text.

Related errors

AI-assisted analysis of Mintplex-Labs/anything-llm@3aec848f28 (2026-08-18). Data as JSON: /api/errors/0526f0b110a9932d. Report an issue: GitHub.

Appendix: source

Thrown at server/utils/SpeechToText/deepgram/index.js:74

      body: audioBuffer,
    })
      .then(async (response) => {
        if (!response.ok) {
          const errBody = await response.text().catch(() => "");
          throw new Error(
            `Deepgram transcription failed (${response.status}) - ${errBody}`
          );
        }
        return response.json();
      })
      .then((result) => {
        return (
          result?.results?.channels?.[0]?.alternatives?.[0]?.transcript ?? ""
        );
      })
      .catch((error) => {
        this.#log(`Deepgram transcription failed - ${error.message}`);
        throw new Error(`Deepgram transcription failed - ${error.message}`);
      });
  }
}

module.exports = { DeepgramSTT };

View on GitHub (pinned to 3aec848f28)