[finding] Test Core (5/6) times out at its 30-minute ceiling for any PR touching packages/spec — measured twice at 30.3 min on one head, siblings pass in 20-26

[claude]

Test Core (5/6) does not fit its 30-minute ceiling for a PR that touches packages/spec. Measured twice on the same head, at the same duration to the tenth of a minute, so it is a ceiling being hit rather than variance.

The measurement

PR #16376 (@objectstack/driver-turso + packages/spec), head 8c3dd7b3907f821b55a2066b144559ee354fe12a, unchanged across both attempts:

attempt	job	conclusion	duration
first	101521390094	cancelled	30.3 min
re-run	101525969906	cancelled	30.3 min

Sibling PRs open at the same time, same shard, same day:

PR	packages touched	Test Core (5/6)	duration
#16057	core	success	25.7 min
#16363	core, runtime	success	25.2 min
#16326	objectql	success	20.1 min

It is a timeout, not a test failure — the step-level reading

step	result
Set up job → Install dependencies → Compute this shard's package set	success
Run this shard's tests	cancelled
Publish turbo run summary · Test completeness guard · Post Checkout	success
Attest this shard ran and passed	skipped

The log ends ##[error]The operation was canceled. mid-stream through @objectstack/cli's suite, with no Failed Tests block, no Test Files … failed, no ELIFECYCLE. ⇒ nothing asserted false. Restore Turbo cache succeeded, so a cache was present.

⚠️ The roll-up check Test Core reports failure because the shard published no attestation — not because it published a failing one. Anyone reading only the roll-up sees "tests failed", which is the wrong diagnosis.

Why packages/spec is the discriminator

A change under packages/spec invalidates the Turbo cache for everything downstream of it, so this shard rebuilds a large part of the tree before running its first test. The siblings above change leaf packages and keep most of their cache. The extra minutes are bought by the rebuild, not by slower tests — so "the tests got slower" would send someone hunting the wrong thing.

Why this is filed rather than worked around

The PR it blocks cannot resolve it from inside itself, and the remedies all sit outside any one PR — a larger timeout-minutes for this shard, a different package split across the six shards, or a warm build step ahead of the shard. ⛔ The things a PR could do — skip, quarantine or narrow tests to fit the window, or push empty commits hoping for a faster runner — are all forbidden and would hide this rather than fix it.

⛔ Not asserted here: which remedy is right, or whether the ceiling should move. Severity and lane are triage's; this card carries the measurement so the next packages/spec PR does not have to rediscover it. The one permitted re-run has been spent on #16376 and its result is the second row of the first table.

Re-check

gh api repos/objectstack-ai/objectstack/actions/jobs/101521390094 --jq '{conclusion,started_at,completed_at}'
gh api repos/objectstack-ai/objectstack/actions/jobs/101525969906 --jq '{conclusion,started_at,completed_at}'

Refs: #16376 · #16024

---

Generated by Claude Code