Observation found while implementing #13347 (PR on claude/issue-13347-cli-json-error-code). Not that card's defect, not fixed there, and filed rather than folded in.
What was measured
One run of the affected package's own suite, on a shared agent container, through the repo's verify lock:
NODE_OPTIONS=--max-old-space-size=4096 pnpm --filter @objectstack/cli exec vitest run --maxWorkers=2
Test Files 220
Tests 2525
Duration 1436.54s (transform 40.46s, import 401.08s, tests 2419.71s)
and the lock wrapper's own verdict line for that run:
os-verify-lock: VERDICT command-exit 1 · held the lock 1438s (23m58s) · waited 10s
os-verify-lock: ⚠ THIS RUN held the shared verify lock for 1438s (23m58s). Every sibling agent
os-verify-lock: ⚠ in this container queued behind it, and a long holder lengthens every cycle for
os-verify-lock: ⚠ all of them.
os-verify-lock: ⚠ If that is normal for this command rather than a one-off, it is a finding worth
os-verify-lock: ⚠ filing (holder-side starvation) — narrow the run, or say so on the card.
It is normal for this command rather than a one-off: 2419s of the 1436s wall clock is test body time across 220 files (the two numbers differ because --maxWorkers=2 runs two files at once), so the cost is the suite's own shape, not a stall or a hung case.
Why it is worth recording
pnpm test for the affected package is a Definition-of-done step for every card that touches packages/cli, and this repo runs several agents in one container behind a single verify lock. So every such card either
- holds the shared lock for ~24 minutes, starving every sibling agent for the whole of it (the wrapper's own warning), or
- narrows the run and declares the narrowing — which is legitimate, but means the package's full suite is in practice measured by CI alone.
Neither is wrong; the point is that the choice is currently forced by the suite's runtime rather than made deliberately.
Where the time sits, from the same run: import 401.08s is a quarter of the wall clock before any assertion executes, and a large share of the files boot a real kernel (bootSchemaStack / ObjectQL / a real driver) rather than exercising a unit. Whether the remedy is sharding, a slow-suite split, or moving some of the kernel-booting cases to a narrower double is exactly the triage this card is asking for, not something it presumes.
Deliberately not claimed here
- ⛔ No test is slow "wrongly" — no case was inspected for waste, and several of the heaviest are integration pins whose whole value is that they boot the real thing.
- ⛔ Nothing about CI. CI shards this suite and is not the surface with the contention; the measurement above is about the shared agent container.
Observation found while implementing #13347 (PR on
claude/issue-13347-cli-json-error-code). Not that card's defect, not fixed there, and filed rather than folded in.What was measured
One run of the affected package's own suite, on a shared agent container, through the repo's verify lock:
and the lock wrapper's own verdict line for that run:
It is normal for this command rather than a one-off: 2419s of the 1436s wall clock is test body time across 220 files (the two numbers differ because
--maxWorkers=2runs two files at once), so the cost is the suite's own shape, not a stall or a hung case.Why it is worth recording
pnpm testfor the affected package is a Definition-of-done step for every card that touchespackages/cli, and this repo runs several agents in one container behind a single verify lock. So every such card eitherNeither is wrong; the point is that the choice is currently forced by the suite's runtime rather than made deliberately.
Where the time sits, from the same run:
import 401.08sis a quarter of the wall clock before any assertion executes, and a large share of the files boot a real kernel (bootSchemaStack/ObjectQL/ a real driver) rather than exercising a unit. Whether the remedy is sharding, a slow-suite split, or moving some of the kernel-booting cases to a narrower double is exactly the triage this card is asking for, not something it presumes.Deliberately not claimed here