`ci.yml` `Test (coverage)` has failed 100% of the time since 2026-08-16 — one test times out under v8 coverage, and Codecov has received nothing since

[claude]

Found while re-measuring the CI cost model for #5395. Filing it separately because it is a
concrete defect, not a cost question, and neither #5393 (cost) nor #5394 (QUICK_REFERENCE.md
drift) covers it. Not assigned to anyone and nothing has been changed — this card is a
measurement card and did not touch it.

ci.yml's Test (coverage) job has failed 100% of the time since 2026-08-16, so Codecov has received nothing since

last successful Test (coverage) job	2026-08-16T10:56:13Z, run 31942979071
last successful Upload coverage to Codecov step	the same run
completed Test (coverage) jobs since then	51, every one a failure, 0 successes
window examined	373 coverage jobs across 378 unfiltered push/main ci.yml runs, 2026-08-12 .. 2026-08-20

The Upload coverage to Codecov step has no if:, so it carries the implicit success() and
is skipped whenever the test step fails. It is skipped in 311 of the 373 coverage jobs, and
in 120 of the 121 most recent ones.

It is one test, and it is a timeout not an assertion

Reading GitHub's check-run annotations for all 51 completed failures:

failing test file	occurrences
scripts/__tests__/check-package-self-import.test.ts	50
scripts/__tests__/quick-reference-current-release-4143.test.ts	3 (the #5394 drift, recent only)
three others, one run on 2026-08-17	1 each

[unit] scripts/__tests__/check-package-self-import.test.ts
 > a package name that is not a module edge is not a finding
 > the two live specimens in this repository stay unflagged
Error: Test timed out in 15000ms.
 at scripts/__tests__/check-package-self-import.test.ts:140:3

First occurrence 2026-08-16T12:48:02Z — the run immediately after the last green one.

The discriminator is v8 coverage instrumentation, not load — measured by ablation

lane	sharded?	v8 coverage?	does it time out?
PR lane (production), 220 runs sampled	yes, 4 ways	no	no — 0 occurrences
push lane (production), 373 coverage jobs	no	yes	yes — 50 of 51 completed failures
throwaway prototype, same commit, run 32364577842	yes, 4 ways	yes	yes

Counter-probe for the PR-lane zero: the identical annotation scan over the identical PR shard
jobs does return results (7 annotations naming vite-alias-closure.test.ts,
AppContent.systemHubRoutes.test.tsx, vite-objectstack-spec-dist.test.ts,
check-type-check-coverage.test.ts, check-changeset-no-major.test.ts), and the same call
against the push lane returns 50 hits for this file. The method resolves; the zero is real.

So splitting the job 4 ways does not fix it — that was measured, not assumed. Coverage
instrumentation pushes this one test past its 15-second budget regardless of how much else is
running alongside it.

Per AGENTS.md's testing section, the fix direction for "an unbounded cost inside a bounded
window" is to find the race rather than raise the timeout — this issue records the measurement,
not a prescription.

Second, independent symptom found while prototyping

On a failing suite, the live unsharded recipe
(pnpm test:coverage --coverage.reporter=json --coverage.reporter=text) leaves no
coverage/ directory at all. Reproduced 2 of 2 on the same commit — run 32364577842
(NO COVERAGE FILE at coverage/coverage-final.json, after 39m05s) and run 32368063518
(NO coverage/ DIRECTORY AT ALL after the live unsharded run, after 39m25s) — while the same
tree run through vitest's blob-report path produced a complete 1287-file report every time.

So there are two independent reasons Codecov is dark, not one: the upload step is skipped by its
implicit success(), and there would be no file for it to upload anyway. As long as the
suite is red, this job cannot produce a coverage report at all. The mechanism was not identified
— the Actions log CDN is blocked from the measuring session.

Why this matters beyond coverage percentages

ci.yml's own comment justifies keeping this job unsharded as "one unsharded run so Codecov
still receives a single complete report". That justification has been delivering nothing for
four days, which is worth knowing before #5393 is ruled on.

Full measurement, method and counter-probes: #5395.

---

Generated by Claude Code

[os-support-ai]

Claim: PM loop round 20
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5402-coverage-timeout
Worktree: objectui-issue-5402
Domain: repo:objectui
File surface: scripts/__tests__/check-package-self-import.test.ts and whatever the race actually turns out to be in scripts/check-package-self-import.mjs or the coverage config (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — does not change contract accept/reject behaviour or widen any public surface; it restores a gate that has been failing 100% of the time
Serial constraints cleared: ⛔ not .github/workflows/ci.yml — #5403 owns that file and is pm:blocked behind this card, so nothing is editing it concurrently. #5405 (release.yml) and #5406 (vitest guard) are claimed in the same round with disjoint surfaces. No open PR touches check-package-self-import.

This card is item 1 of the maintainer's 2026-08-20 ruling on #5393 and gates items 2 and 3 (#5403, #5404) — those two remove or replace post-merge validation and are only safe once the push lane genuinely passes.

---

Generated by Claude Code

[os-support-ai]

{
 "issue": 5402,
 "status": "done",
 "branch": "claude/issue-5402-coverage-timeout",
 "pr": "https://github.com/objectstack-ai/objectui/pull/5411",
 "premise_still_valid": true,
 "summary": "Confirmed the issue's premise and answered the mechanism question: it is NOT a race, it is the 'real work proportional to repo size times a coverage constant factor' answer. scripts/__tests__/check-package-self-import.test.ts full-parses every source file of every workspace package (44 packages, 3,094 files, 30.3 MB, 15,550 module specifiers) TWICE for identical inputs -- once in the describe('objectui itself') body and once inside the it() at line 140 -- because the two assertions differ only in which exemption table they judge under, and the parse does not depend on that table at all. The constant factor is compile-order: @vitest/coverage-v8 arms Profiler.startPreciseCoverage({callCount, detailed}) in the worker BEFORE test modules and their dependencies compile, V8 emits those block counters at compile time and does so isolate-wide, so node_modules/typescript is instrumented too (coverage.exclude filters the report, never the instrumentation). Isolated in a plain node process: the identical parse over the identical corpus costs 4919/4105 ms with coverage off and 34941/32230 ms with coverage armed first (7.1x-7.9x), while arming coverage AFTER the same code is compiled and warmed costs nothing at all (4254 ms -> 4184 ms). Fix: split the gate's expensive exemption-independent scanRepository(root) from the pure judgeScan(scan, exemptions); analyze() keeps its signature and behaviour and is now exactly the composition. The test scans once at module scope and judges per assertion. No timeout raised, nothing skipped/quarantined/deleted, coverage not disabled for anything, ci.yml untouched. SECOND SYMPTOM SOLVED AND IT IS A CONSEQUENCE, NOT A SECOND DEFECT: vitest's v8 provider runs `if (!this.options.reportOnFailure) await this.cleanAfterRun();` (coverage.DM_a_rWm.js:791) and reportOnFailure defaults to false (defaults.9aQKnqFk.js:22), which vitest.config.mts does not override -- so a RED run has its reports directory deleted. Demonstrated on my two ablation legs with the same command, same tree, same configured reporters: red run -> no coverage/ directory, green run -> coverage/ with coverage-final.json. It needs no separate fix and clears when the suite goes green; whether red runs should still emit partial coverage is a policy call left to #5403, whose file I did not touch.",
 "tests": "All from the repo root. Gate union re-derived from the actual changed paths and run at the FINAL commit f1f0da7c3 (changed: scripts/check-package-self-import.mjs, scripts/__tests__/check-package-self-import.test.ts, .changeset/self-import-gate-scan-once-5402.md): check:self-import PASS, check:phantom-deps PASS, check:control-bytes PASS, check:esm-specifiers PASS, type-check:coverage PASS, lint:coverage PASS, type-check:scripts PASS, check-changeset-no-major/fixed/presence PASS, eslint on both edited files PASS. || REPRODUCTION BEFORE FIX, under coverage: 'the two live specimens in this repository stay unflagged' 41268ms -> 'Error: Test timed out in 15000ms. at scripts/__tests__/check-package-self-import.test.ts:140:3'; Test Files 1 failed (1); Tests 1 failed | 23 passed (24); Duration 84.81s (import 42.86s, tests 41.31s). Same test WITHOUT coverage: 8782ms, pass -- i.e. already at 59% of the 15s budget when green, every other test in the file under 10ms. || AFTER FIX, under coverage: same test 1ms; Test Files 1 passed (1); Tests 28 passed (28); Duration 45.16s (import 44.18s, tests 0.077s). Largest test in the file 15ms against a 15000ms budget. || pnpm exec vitest run scripts/__tests__/ -> Test Files 58 passed (58), Tests 1553 passed (1553). (Before merging origin/main it was 57 files with quick-reference-current-release-4143.test.ts red -- that is the #5394 drift, fixed on main in fd227eae1 AFTER my branch point; merged in fast-forward and it is green. Never mine.) || BEHAVIOUR-PRESERVATION OF analyze(): (a) CLI output byte-identical to origin/main's version, both run with --root over this repository, diff clean and same exit code; (b) differential harness comparing old vs new analyze() on findings, counters and packages over a fixture tree AND this repository across all six exemption-table shapes (empty, covering, stale-file, stale-specifier, no-reason, no-specifiers) plus the default-table path = 14 cases, all identical. || REVERSE VERIFICATION (predicted before running). BUILD ARTIFACT: none on either leg -- the test imports ../check-package-self-import.mjs by relative path, a plain ESM source file transformed in-memory by vitest, never through a package exports map or a dist/, so no rebuild is possible or needed and this is not one of the dist-resolved pairs where an unbuilt ablation stays falsely green. Ablation = revert ONLY the test-file half to origin/main (git checkout origin/main -- <test file>), keeping the gate split, fix already committed first. PREDICTED: 1 failed test, namely the specimens test with 'Test timed out in 15000ms' at :140:3; 24 tests total with 23 passed (the 4 new purity tests vanish with the reverted file); ~85s; and NO coverage/ directory. OBSERVED: exactly that -- 1 failed, 'the two live specimens in this repository stay unflagged', 'Error: Test timed out in 15000ms.' at 'scripts/__tests__/check-package-self-import.test.ts:140:3', Tests 1 failed | 23 passed (24), Duration 86.05s, and 'ls: cannot access coverage: No such file or directory'. RESTORE LEG (git checkout HEAD -- <test file>, tree clean): PREDICTED 28 passed, ~45s, coverage/ present; OBSERVED 28 passed, 44.87s, coverage/ present with coverage-final.json. Both legs matched every predicted count.",
 "open_questions": [
 {
 "question": "Should the coverage lane set `coverage.reportOnFailure: true` in vitest.config.mts, so a RED run still emits a partial coverage/ report instead of having the directory deleted? This is the mechanism behind the issue's second symptom. I deliberately did not decide it: it is a policy change to the coverage lane rather than a defect, it is moot for THIS card (the symptom clears once the suite is green, demonstrated on both ablation legs), and the ci.yml upload step is gated by its implicit success() anyway so it would not upload on red without #5403 also changing.",
 "options": [
 "A. Leave the default (false). Red runs produce no report; coverage only ever reflects a fully green suite, which is the stricter and arguably more honest reading, and nothing partial can be mistaken for a real number.",
 "B. Set reportOnFailure: true in vitest.config.mts. A red run still leaves coverage/ behind, which makes a future occurrence of this class diagnosable from the artifact rather than only from the annotation, but the file would be partial and must not be uploaded as if complete.",
 "C. Hand it to #5403 as part of its ci.yml redesign, since that card owns the coverage lane end to end and can decide the config and the upload gating together."
 ],
 "recommendation": "C, then A unless #5403 finds it needs the artifact. C because #5403 owns ci.yml and the upload step, and deciding the config half here would split one decision across two PRs. A as the default landing spot because the value of a partial report is diagnostic only, and this particular failure was already fully diagnosable from the check-run annotations; B buys little and creates a file that reads as a coverage number without being one."
 }
 ],
 "out_of_scope_findings": [
 "filed as #5410: `moduleSpecifiers()` in scripts/check-phantom-dependencies.mjs passes `setParentNodes: true` to ts.createSourceFile and nothing reads a parent (the walk is forEachChild, and getStart is handed the source file explicitly). Measured 3600ms vs 4800ms over the same 3,094 real files with output compared both ways on every one of them and ZERO differences -- ~25% off the dominant cost of two gates for no behavioural change, worth ~7x that under coverage. Not taken in this PR because it changes a parser shared with check:phantom-deps and so widens the verification surface beyond this card. Unassigned, labelled `finding`."
 ]
}

---

Generated by Claude Code