Mintplex-Labs/anything-llm · warning

${LOG_PREFIX} ANYTHINGLLM_FETCH_TIMEOUT="${envDefinedTimeout

Error message

${LOG_PREFIX} ANYTHINGLLM_FETCH_TIMEOUT="${envDefinedTimeout}" is not a valid positive integer — using default ${DEFAULT_TIMEOUT_MS}ms.

What it means

patchSdkTimeouts parsed ANYTHINGLLM_FETCH_TIMEOUT with parseInt and the result was NaN or <= 0, so the SDK fetch timeout remains at DEFAULT_TIMEOUT_MS instead of your value. Because parseInt is lenient ('5000x' parses as 5000), this specifically fires for values like 'abc', '0', '-1', or empty-ish garbage.

Source

Thrown at server/utils/boot/patchSdkTimeouts.js:25

 * at least 10 minutes for the 80% use case so
 * the transport layer doesn't kill connections before the SDK does.
 *
 * When `ANYTHINGLLM_FETCH_TIMEOUT` is set (milliseconds), both the undici
 * dispatcher and the SDK-level AbortController deadline are raised to that
 * value instead — for users with slow local models that need even longer.
 *
 * Must be called before any provider module is required.
 */
function patchSdkTimeouts() {
  const envDefinedTimeout = process.env.ANYTHINGLLM_FETCH_TIMEOUT;
  const envDefinedMaxRetries = process.env.ANYTHINGLLM_MAX_RETRIES;
  let timeoutMs = DEFAULT_TIMEOUT_MS;
  let maxRetries = DEFAULT_MAX_RETRIES;

  if (envDefinedTimeout) {
    const parsed = parseInt(envDefinedTimeout, 10);
    if (!Number.isFinite(parsed) || parsed <= 0) {
      console.warn(
        `${LOG_PREFIX} ANYTHINGLLM_FETCH_TIMEOUT="${envDefinedTimeout}" is not a valid positive integer — using default ${DEFAULT_TIMEOUT_MS}ms.`
      );
    } else {
      timeoutMs = parsed;
    }
  }

  if (envDefinedMaxRetries) {
    const parsed = parseInt(envDefinedMaxRetries, 10);
    if (!Number.isFinite(parsed) || parsed < 0) {
      console.warn(
        `${LOG_PREFIX} ANYTHINGLLM_MAX_RETRIES="${envDefinedMaxRetries}" is not a valid non-negative integer — using default ${DEFAULT_MAX_RETRIES}.`
      );
    } else {
      maxRetries = parsed;
    }
  }

View on GitHub (pinned to 3aec848f28)

Solutions

  1. Set ANYTHINGLLM_FETCH_TIMEOUT to a plain positive integer in milliseconds (e.g. 60000 for 60s).
  2. Remove units/quotes/spaces from the value.
  3. Re-save the env file with LF line endings and no BOM.
  4. Check the companion variable ANYTHINGLLM_MAX_RETRIES for the same formatting problems.

Example fix

# before
ANYTHINGLLM_FETCH_TIMEOUT=10s

# after
ANYTHINGLLM_FETCH_TIMEOUT=10000
Defensive patterns

Strategy: validation

Validate before calling

// Fail fast on bad numeric env values at boot:
const t = process.env.ANYTHINGLLM_FETCH_TIMEOUT;
if (t != null && (!/^\d+$/.test(t) || Number(t) <= 0)) {
  throw new Error(`ANYTHINGLLM_FETCH_TIMEOUT="${t}" must be a positive integer (ms)`);
}

Type guard

function isPositiveIntegerEnv(value) {
  return /^\d+$/.test(value ?? '') && Number(value) > 0;
}

Prevention

When it happens

Trigger: ANYTHINGLLM_FETCH_TIMEOUT set to '0', a negative number, or a non-numeric string; .env saved with CRLF/BOM corrupting the value; quoting artifacts from compose files producing an unparseable string.

Common situations: Operators copying timeout values with units attached ('10s'); CI injecting an empty string rather than unsetting; Windows-edited env files.

Understand the failure class

Background: "is not a valid" / "Invalid ... value" environment variable errors: how libraries validate env vars and what to do when they reject yours — this error's family across 48 libraries.

Related errors


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