Chinesezjc
d3d66926fb
`config.maxWallMs` is only checked for positivity, and it is handed to `setTimeout`, which clamps any delay above 2^31-1 ms to 1 ms. A deployment configuring a 25-day wall ceiling therefore gets the opposite of what it asked for: every run times out on the first tick. The runtime now range-checks the field at load against MAX_TIMER_DELAY_MS from dsh-timeout and throws, so the misconfiguration fails loud where it is self-contained instead of silently inverting the budget. `computeMs` needs no matching bound: it is compared against measured event-loop utilization rather than fed to a timer. The test asserts both the rejection and that the boundary value itself loads.
code-runtime/ — code-execution capability family
English | 中文
The code-execution capability seam (see capability seams): an abstract runtime interface for executing one model-written program against host-provided async bindings, capturing what it printed and returned. The consumer is the tool registry's Code Mode (tools: { mode: code } — the run_code tool and the generated TypeScript SDK); design in the Code Mode Agent Note. Product packages.
| Package | Role | ctx key |
|---|---|---|
code-runtime/ |
Abstract code-execution seam (interface + vocabulary) | ctx.codeRuntime |
code-runtime-worker/ |
Worker-thread backend: fresh worker per run, TypeScript via host-side type-strip (annotations advisory, never type-checked), port-bridged bindings, budget/heap containment | registers ctx.codeRuntime |
The interface lives at code-runtime/code-runtime/; the shipped backend at code-runtime/code-runtime-worker/. Backends differ by execution substrate (worker thread, process, container) and by source language — both readonly descriptors on the service — and register ctx.codeRuntime without touching the interface or its consumer; that split is what makes a hardened backend a drop-in later.