Mintplex-Labs/anything-llm · error · Error
e.message
Error message
e.message
What it means
The .catch((e) => { throw new Error(e.message); }) wraps ANY failure from openai.chat.completions.create (auth, rate limit, 4xx/5xx, network) into a plain Error carrying only the string message. This loses the original error class, status code, headers, and retry-after info — an info-loss anti-pattern. The literal 'e.message' is the source token; at runtime the message is the upstream error's text.
Source
Thrown at server/utils/AiProviders/minimax/index.js:96
};
return [prompt, ...chatHistory, { role: "user", content: userPrompt }];
}
async getChatCompletion(messages = null, { temperature = 0.7 }) {
if (!(await this.isValidChatCompletionModel(this.model)))
throw new Error(
`Minimax chat: ${this.model} is not valid for chat completion!`
);
const result = await LLMPerformanceMonitor.measureAsyncFunction(
this.openai.chat.completions
.create({
model: this.model,
messages,
temperature,
})
.catch((e) => {
throw new Error(e.message);
})
);
if (
!result?.output?.hasOwnProperty("choices") ||
result?.output?.choices?.length === 0
)
throw new Error(
`Invalid response body returned from Minimax: ${JSON.stringify(result.output)}`
);
return {
textResponse: result.output.choices[0].message.content,
metrics: {
prompt_tokens: result.output.usage.prompt_tokens || 0,
completion_tokens: result.output.usage.completion_tokens || 0,
total_tokens: result.output.usage.total_tokens || 0,
outputTps: result.output.usage.completion_tokens / result.duration,View on GitHub (pinned to 526360e320)
Solutions
- Inspect the full message text — it usually contains the upstream status/detail.
- If the message indicates 401/auth, rotate/verify MINIMAX_API_KEY.
- If it indicates 429 or timeout, reduce request rate and retry with backoff.
- For diagnosis, temporarily log e (not just e.message) upstream, or patch the catch to rethrow the original error.
Example fix
// before
.catch((e) => {
throw new Error(e.message); // loses status/type
})
// after
.catch((e) => {
const status = e?.status ?? e?.response?.status;
const err = new Error(`Minimax chat failed (${status}): ${e.message}`);
err.cause = e;
err.status = status;
throw err;
}) Defensive patterns
Strategy: retry
Try / catch
// The message string is all you get; branch on known substrings
try {
await llm.getChatCompletion(messages, { temperature });
} catch (e) {
const msg = e.message || '';
if (/429|rate limit/i.test(msg)) { /* backoff and retry */ }
else if (/401|unauthor|invalid api key/i.test(msg)) { /* rotate key */ }
else if (/timeout|etimedout/i.test(msg)) { /* retry once */ }
else { /* surface as hard error */ }
} Prevention
- Prefer patching the catch to rethrow e (or attach e.cause/e.status) so callers can branch on type.
- Log the original error object during incident diagnosis, not just e.message.
- Add a retry-with-backoff layer for 429/5xx upstream errors.
When it happens
Trigger: Any upstream failure during the Minimax chat completion HTTP call: 401 (bad key), 429 (rate/quota limit), 400 (malformed messages), network/timeout, or 5xx from Minimax. Each surfaces here as a generic Error with only the message string.
Common situations: Expired or revoked API key surfacing as an auth error string; hitting Minimax rate/quota limits; a malformed message array; transient upstream outage; the re-wrap making it impossible to distinguish 429 from 5xx in a catch block.
Related errors
AI-assisted analysis of Mintplex-Labs/anything-llm@526360e320 (2026-08-13).
Data as JSON: /api/errors/6cc892cc122e0ac5.
Report an issue: GitHub.