The managed-scope disposal cases in subprocess-local and bash-sandbox run past
the 5000ms default when this lane's four partitions, six workers per gate, and
sibling gates share one host. The same commit stays inside the budget on the
in-house pool: the hosted image exceeded it (run 34449848541) and the lane is
green with 90000 (run 34457655892). The Windows coverage lane already grants
the same budget for the same class of teardown.
The per-platform failover repository variables (DSH_CI_FAILOVER_LINUX and
DSH_CI_FAILOVER_WINDOWS) accept a third value alongside the existing
selfhosted routing. Set by a repository writer, the value retargets the
always-on pull-request and master lanes onto the matching hosted-runner
labels (16-core pools map to the 16-vCPU tier, standard legs to 4-vCPU);
unset or any other value keeps today's runners, so the leg is dormant until
a writer opts in - a canary path for capacity fallback, never the default.
Participating jobs: the three enterprise Linux workers, the node-compat
legs, the four Windows lanes, and the all-checks-passed verdict in ci.yml;
expected-filenames; the sandbox bwrap leg; and the two manual benchmark
matrices (4-32 vCPU tiers map to equivalents; 64/96-core rows keep the
fleet labels). Everything pinned to its own runner by spec, credential, or
host capability keeps it under every value, and the release-shaped chains
stay entirely hosted. request-review.yml was retired on master while this
work was in flight and the branch takes the deletion.
Specs pin the new branches: ci-workflow.spec.ts asserts the labels appear
in the extended selectors, and ci-compatible-selfhosted.spec.ts evaluates
the routing mode.
Add a benchmark lane (`vitest.bench.config.ts`, `pnpm run test:bench`,
gate mode `ci-bench`) and a required `node 24 / benchmarks` CI job that
runs it alone. Benchmarks synthesize their input in-process from fixed
parameters and fail on documented budgets:
- `open-generation.bench.ts`: a 200-turn released-v0 log with 500 text
and 125 reasoning deltas per reply (127,400 events, ~2.8 MB) encoded
through the frozen v0 codec; the migrating first `open()` must finish
within 2,000 ms in a child process capped at 128 MB of old space, and a
fresh process must open the published current generation within 500 ms.
- `conversation-fold.bench.client.ts`: 200 replies whose compact streams
hold 2,000 text + 500 reasoning deltas each, folded through every Chat
Definition by the real assembler; the fold must finish within 150 ms
and stay within 3x the fold of the same window with 100 deltas per
reply.
On this commit both gates fail: the migration exhausts the 128 MB heap
(4.8 s and 696 MB peak RSS without the cap; the pre-stack decode of the
same bytes took 34 ms and 168 MB) and the fold scales 11x with the delta
count. The stacked fixes bring both paths to O(records).
Resolve the 08-08 note conflict (keep the zero-build rewrite, drop the
SQLite busy-journal sentence removed with the SQLite backend) and drop the
now-removed session-persistence-sqlite built-package suite from the
lib-consuming self-skip inventory in the ci.yml comment, the
ci-workflow.spec.ts comment, and the partitioned-coverage note; the
inventory is now image-loadable, transform-corpus, and client-bundle.
client-bundle.client.spec.ts reads packages/client/ui-trajectory/lib/client.js
and skips all three cases when the bundle is absent, so it is a fourth
lib-consuming suite in the instrumented corpus. List it beside built-package
in the ci.yml comment, the ci-workflow.spec.ts comment, and the
partitioned-coverage note (both languages).
Strengthen the ci-workflow.spec.ts guard to match any 'pnpm run build'
spelling (corepack prefix, multi-line run blocks) instead of one exact
string, and complete the lib-consuming self-skip inventory with the
webworker-runtime transform-corpus import sweep alongside the packer
image assertions and the built-package check. Update the ci.yml comment
and the partitioned-coverage note (both languages) to match, and drop the
stale 'post-build' phase wording and the native-Windows build-wait
rationale from the coverage-exempt comment.
The windows-coverage job built the workspace before running the same
ci-coverage gates as Linux, but the instrumented corpus resolves
workspace imports to src through the tsconfig paths map and never
consumes lib/; the two lib-consuming suites (webworker-packer
image-loadable, session-persistence-sqlite built-package) self-skip on
unbuilt checkouts, exactly how the Linux lane already runs them. Remove
the build step so both lanes behave identically, and pin the zero-build
invariant in ci-workflow.spec.ts (red before this change, green after).
Agent Notes updated in place: corrected the build-wait rationale and the
wrong attribution of the packer assertions to the instrumented suite.
pnpm hardlinks node_modules files to the store on the same volume, and
TypeScript's native realpath resolves those links back to store paths
(F:/.pnpm-store/v11/files/...), producing TS6231 during tsc -b and vite
resolution. ReFS block cloning (package-import-method=clone) gives each
file an independent path while sharing physical blocks, avoiding the
leak without the copy cost. Clone mode needs the @reflink/reflink native
module, which the system corepack pnpm carries but pnpm/action-setup's
dest build omits, so installs run through corepack pnpm.
The install steps branch on the workspace filesystem: clone only on
ReFS, plain install on hosted NTFS (which rejects copy-on-write). The
serial-windows store points at F:\.pnpm-store to share the ReFS volume.
Agent Note 2026-08-30-windows-refs-store-block-clone-install records the
rationale; ci-workflow.spec asserts the branch.
Replace Vitest's hash-based --shard with a coordinator-side
longest-processing-time assignment. The coordinator collects the
instrumented inventory from a vitest list run (dropping the exempt
heavy suites that list does not exclude), reads per-file durations from
the Vitest results cache, and seeds heavy subprocess-bound suites into
different partitions. A weight-aware test fails when assignment ignores
recorded weights, verified by injecting a file-count-only rule.
Windows coverage measured partition spread of 442s (275-717s) under
hash sharding; a simulation with the same file durations and the new
assignment balances partitions to within 21s, cutting the critical
partition to roughly half.
Stacked on #3115: keep its windows-* setup-pnpm-js-<run_id>-<run_attempt>-<job>
destination, and extend the same isolation to non-Windows jobs in ci.yml
and ci-master.yml with setup-pnpm-<run_id>-<run_attempt>. This prevents
sequential self-hosted Windows jobs from tripping over a stale locked
pnpm.exe/reflink native module.
The per-case 15-30s budgets on the Windows native and coverage lanes fire
before oxlint, workflow-worker-thread, and other subprocess-spawning cases
finish under the loaded self-hosted pool; the failures rotate across cases
as load shifts, so per-case widening only moved the flake. Raise the lane
defaults (DSH_COVERAGE_TEST_TIMEOUT_MS and the native --testTimeout) to 90s,
align the oxlint and workflow-worker-thread case budgets, and keep the
built-bin SPAWN_TIMEOUT_MS at 60s under a 90s outer budget.
The windows-* jobs now install pnpm under a run/attempt/job-suffixed
destination, so the pre-install step that cleared the old fixed
setup-pnpm-js path no longer touches the actual destination and its
comment claims stale state. The suffix already gives every job a fresh
directory, so remove the four cleanup steps.
The windows-* jobs keep a separate standalone pnpm executable under
runner.temp/setup-pnpm-js. A previous job on the same self-hosted runner
can leave a locked @reflink native module there, so the next job's
pnpm/action-setup fails with EPERM during unlink before any test runs.
Suffix the destination with run_id, run_attempt, and job so every job
gets a fresh directory even when sequential jobs land on the same
runner; apply the same to the python SDK exe build. Update the pnpm
setup isolation note to record the Windows-specific destination.
Other PRs are blocked by Windows ACP half-close tests timing out. Keep the
coverage job running for signal, but remove it from all-checks-passed.needs
until the Windows skip fix is validated.
These tests spawn real ACP child subprocesses. On contended self-hosted
Windows runners the default 30s budget times out. Instead of raising the
global coverage timeout, give this file 2x the configured default
(DSH_COVERAGE_TEST_TIMEOUT_MS) so it follows future default changes.
After the 4-partition split, other PRs' windows coverage now fails on
process-bound subagent-acp tests timing out at 30s under self-hosted
concurrency. Give the coverage lane the same 60s per-test budget that the
earlier failover profile used.
Chinesezjc