deepseek-ai/deepseek-harness · error

dsh-code-runtime-worker-thread: config.maxWallMs must be at

Error message

dsh-code-runtime-worker-thread: config.maxWallMs must be at most ${MAX_TIMER_DELAY_MS} (Node clamps a longer setTimeout delay to 1ms), got ${String(this.config.maxWallMs)}

What it means

maxWallMs backs the wall-clock kill timer, which is a setTimeout. Node clamps any delay above 2,147,483,647 ms (about 24.9 days) to 1 ms, so a larger ceiling would kill the run immediately instead of late. The constructor therefore rejects maxWallMs above MAX_TIMER_DELAY_MS at load.

Source

Thrown at packages/code-runtime/code-runtime-worker-thread/src/index.ts:268

  private readonly live = new Set<LiveRun>()
  private disposed = false

  constructor(ctx: Context, config: Config) {
    super(ctx)
    // Schemastery filled the defaults; the cast records that. Positivity is a
    // semantic check the schema's plain number type does not carry.
    this.config = config as ResolvedConfig
    for (const [key, value] of Object.entries(this.config)) {
      if (!(Number.isFinite(value) && value > 0)) throw new Error(`dsh-code-runtime-worker-thread: config.${key} must be a positive number, got ${String(value)}`)
    }
    if (!Number.isSafeInteger(this.config.maxOutputBytes) || this.config.maxOutputBytes < MIN_OUTPUT_BYTES) {
      throw new Error(`dsh-code-runtime-worker-thread: config.maxOutputBytes must be a safe integer of at least ${MIN_OUTPUT_BYTES}, got ${String(this.config.maxOutputBytes)}`)
    }
    // maxWallMs reaches setTimeout, which clamps any delay above
    // MAX_TIMER_DELAY_MS to 1 ms; the positivity check above accepts such a
    // value, so a 25-day ceiling would time the run out immediately.
    if (this.config.maxWallMs > MAX_TIMER_DELAY_MS) {
      throw new Error(`dsh-code-runtime-worker-thread: config.maxWallMs must be at most ${MAX_TIMER_DELAY_MS} (Node clamps a longer setTimeout delay to 1ms), got ${String(this.config.maxWallMs)}`)
    }
    ctx.effect(() => () => this.teardown(), 'worker code-runtime teardown')
  }

  /**
   * Dispose to quiescence: mark the service unusable, fail every in-flight
   * run as aborted, and AWAIT each worker's exit so no worker outlives the
   * fiber.
   */
  private async teardown(): Promise<void> {
    this.disposed = true
    const runs = [...this.live]
    for (const run of runs) run.settle({ kind: 'abort', message: 'runtime disposed' })
    await Promise.all(runs.map(run => run.finished))
  }

  /**
   * Execute one program in a fresh worker. Program outcomes — including a

View on GitHub (pinned to b150a551b8)

Solutions

  1. Cap maxWallMs at 2147483647 or lower (default 600000 = 10 minutes).
  2. If longer effective wall time is needed, restructure into resumable or checkpointed runs instead of one long run.
  3. Re-check the unit math — the value is milliseconds.

Example fix

# before — 30 days exceeds Node's maximum setTimeout delay
maxWallMs: 2592000000

# after — at or below 2147483647 ms (~24.9 days); default is 600000
maxWallMs: 2147483647
Defensive patterns

Strategy: validation

Validate before calling

const MAX_TIMER_DELAY_MS = 2_147_483_647
if (maxWallMs !== undefined && !(maxWallMs > 0 && maxWallMs <= MAX_TIMER_DELAY_MS)) {
  throw new Error('maxWallMs must be in (0, 2147483647] milliseconds')
}

Type guard

const isValidWallCap = (v: unknown): v is number =>
  typeof v === 'number' && Number.isFinite(v) && v > 0 && v <= 2_147_483_647

Prevention

When it happens

Trigger: cordis.yml sets maxWallMs above 2147483647 — e.g. 2592000000 for 30 days, or a sentinel like Number.MAX_SAFE_INTEGER.

Common situations: Copying an 'effectively unlimited' ceiling from elsewhere; unit confusion (seconds written where milliseconds are expected); genuinely wanting month-long runs, which Node timers cannot express.

Understand the failure class

Related errors


AI-assisted analysis of deepseek-ai/deepseek-harness@b150a551b8 (2026-08-24). Data as JSON: /api/errors/59e828aa67cd63ef. Report an issue: GitHub.