run-llama/liteparse · error · Error

parseTimeoutMs must be > 0

Error message

parseTimeoutMs must be > 0

What it means

WorkerPool validates that parseTimeoutMs, when provided, is a positive number (> 0). A zero or negative timeout would abort every parse instantly, so the constructor rejects it up front. Passing undefined disables timeouts entirely and is allowed.

Solutions

1. Pass a positive millisecond value, e.g. `new WorkerPool(config, 2, 30000)`.
2. Pass `undefined` (omit the argument) to disable timeouts instead of 0.
3. Sanitize: `const t = timeoutMs && timeoutMs > 0 ? timeoutMs : undefined;`

Example fix

// before
const pool = new WorkerPool(cfg, 2, Number(process.env.PARSE_TIMEOUT_MS ?? 0));
// after
const raw = Number(process.env.PARSE_TIMEOUT_MS);
const pool = new WorkerPool(cfg, 2, raw > 0 ? raw : undefined);

const t = Number(process.env.PARSE_TIMEOUT_MS);
const timeoutMs = Number.isFinite(t) && t > 0 ? t : undefined;
if (process.env.PARSE_TIMEOUT_MS !== undefined && timeoutMs === undefined) {
  console.warn('Ignoring non-positive PARSE_TIMEOUT_MS; timeouts disabled');
}

const isValidTimeout = (v) => v === undefined || (typeof v === 'number' && Number.isFinite(v) && v > 0);

let pool;
try {
  pool = new WorkerPool(config, size, timeoutMs);
} catch (e) {
  if (e.message === 'parseTimeoutMs must be > 0') {
    pool = new WorkerPool(config, size, 30000);
  } else throw e;
}

When it happens

Trigger: `new WorkerPool(config, 2, 0)` or `-1000`; computing a timeout from a mis-parsed duration string yielding 0 or NaN (NaN fails `NaN > 0` too); a config UI or env var supplying 0 meaning 'no timeout' when the API expects undefined for that.

Common situations: Env parsing `Number('0')` from PARSE_TIMEOUT_MS=0 intended as 'disabled'; unit tests passing 0; mixing seconds/milliseconds conversions that produce 0 for sub-second values.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

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

Related errors

• parseTimeoutMs requires poolSize
• poolSize must be an integer >= 1
• parse of exceeded ms; the worker process was killed
• parse_timeout must be > 0 seconds
• parser pool is closed

AI-assisted analysis of run-llama/liteparse@22d2dd8cd7 (2026-09-08). Data as JSON: /api/errors/1b29343482e15f75. Report an issue: GitHub.

Appendix: source

Thrown at packages/node/src/pool.ts:205

  private timeoutMs: number | undefined;
  private workers = new Set<WorkerHandle>();
  private idle: WorkerHandle[] = [];
  private waiters: Array<{
    resolve: (w: WorkerHandle) => void;
    reject: (e: Error) => void;
  }> = [];
  private closed = false;

  constructor(
    config: Record<string, unknown>,
    poolSize: number,
    parseTimeoutMs?: number,
  ) {
    if (!Number.isInteger(poolSize) || poolSize < 1) {
      throw new Error("poolSize must be an integer >= 1");
    }
    if (parseTimeoutMs !== undefined && !(parseTimeoutMs > 0)) {
      throw new Error("parseTimeoutMs must be > 0");
    }
    this.config = config;
    this.timeoutMs = parseTimeoutMs;
    // Spawn eagerly: children load the addon and construct their native
    // parsers concurrently while the caller goes on with its own startup.
    for (let i = 0; i < poolSize; i++) {
      this.spawnWorker();
    }
  }

  private spawnWorker(): void {
    const worker = new WorkerHandle(this.config);
    this.workers.add(worker);
    this.release(worker);
  }

  private acquire(): Promise<WorkerHandle> {
    const worker = this.idle.pop();

View on GitHub (pinned to 22d2dd8cd7)