run-llama/liteparse · error · Error

parseTimeoutMs requires poolSize

Error message

parseTimeoutMs requires poolSize

What it means

The Node LiteParse constructor throws when `parseTimeoutMs` is set in the user config but `poolSize` is not. Timeout-based parsing is only implemented via the WorkerPool path, so specifying a timeout without enabling the pool is a configuration contradiction the library refuses rather than silently ignoring the timeout.

Solutions

1. Add `poolSize` to the config alongside `parseTimeoutMs` (e.g. `{ poolSize: 2, parseTimeoutMs: 5000 }`).
2. Remove `parseTimeoutMs` if you do not need pool-based timeouts.
3. Validate that both options are set together in config-loading code before constructing LiteParse.

Example fix

// before
const lp = new LiteParse({ parseTimeoutMs: 5000 });
// after
const lp = new LiteParse({ poolSize: 2, parseTimeoutMs: 5000 });

function assertPoolTimeoutConfig(cfg) {
  if (cfg.parseTimeoutMs !== undefined && cfg.poolSize === undefined) {
    throw new Error('parseTimeoutMs requires poolSize');
  }
}
assertPoolTimeoutConfig(userConfig); // call before new LiteParse(...)

let lp;
try {
  lp = new LiteParse(userConfig);
} catch (e) {
  if (e.message === 'parseTimeoutMs requires poolSize') {
    lp = new LiteParse({ ...userConfig, poolSize: 2 });
  } else throw e;
}

When it happens

Trigger: `new LiteParse({ parseTimeoutMs: 5000 })` without `poolSize`; adding `parseTimeoutMs` to an existing config that never enabled pooling; a config file/template where poolSize was removed but parseTimeoutMs remained.

Common situations: Developers adding a timeout to fix hung parses without realizing it requires the worker-pool mode; environment-driven config where POOL_SIZE is unset but PARSE_TIMEOUT_MS is set.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

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

Related errors

• poolSize must be an integer >= 1
• parseTimeoutMs must be > 0
• Failed to load native module for
• parser pool is closed
• parse of exceeded ms; the worker process was killed

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

Appendix: source

Thrown at packages/node/src/lib.ts:678

      quiet: userConfig.quiet,
      numWorkers: userConfig.numWorkers,
      ocrFailureFatal: userConfig.ocrFailureFatal,
      ocrHedgeDelaysMs: userConfig.ocrHedgeDelaysMs,
      emitWordBoxes: userConfig.emitWordBoxes,
      extractTextMetadata: userConfig.extractTextMetadata,
      cropBox: userConfig.cropBox,
      skipDiagonalText: userConfig.skipDiagonalText,
      includeComplexity: userConfig.includeComplexity,
      extractVectorGraphics: userConfig.extractVectorGraphics,
    };

    this._native = new native.LiteParse(nativeConfig);

    if (
      userConfig.parseTimeoutMs !== undefined &&
      userConfig.poolSize === undefined
    ) {
      throw new Error(
        "parseTimeoutMs requires poolSize"
      );
    }
    if (userConfig.poolSize !== undefined) {
      this._pool = new WorkerPool(
        nativeConfig as unknown as Record<string, unknown>,
        userConfig.poolSize,
        userConfig.parseTimeoutMs,
      );
    }

    // Read back the resolved config from the native side
    const resolved = this._native.config;
    this._config = {
      ocrLanguage: resolved.ocrLanguage ?? "eng",
      ocrEnabled: resolved.ocrEnabled ?? true,
      ocrServerUrl: resolved.ocrServerUrl ?? undefined,
      ocrServerHeaders: resolved.ocrServerHeaders ?? undefined,

View on GitHub (pinned to 22d2dd8cd7)