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 aView on GitHub (pinned to b150a551b8)
Solutions
- Cap maxWallMs at 2147483647 or lower (default 600000 = 10 minutes).
- If longer effective wall time is needed, restructure into resumable or checkpointed runs instead of one long run.
- 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
- Treat 2^31-1 ms as a hard ceiling for any timer-backed config value.
- Use the default or modest budgets; wall time is a backstop — computeMs meters actual busy time.
- Never feed sentinels like Number.MAX_SAFE_INTEGER into timer delays.
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
- Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.
Related errors
- attachment-local: imageCompressionConcurrency must be an int
- client-connection: trustedHosts entry ${JSON.stringify(entry
- client-connection maxRequestBodyBytes (${String(maxRequestBo
- permission settings has no defaultPreset value
- dsh-code-runtime-worker-thread: config.${key} must be a posi
AI-assisted analysis of deepseek-ai/deepseek-harness@b150a551b8 (2026-08-24).
Data as JSON: /api/errors/59e828aa67cd63ef.
Report an issue: GitHub.