The Dogfood Regression Gate carries the same run-level Turbo passthrough defect that #16395 has just fixed in the test job (PR #16868, merged 2026-09-08T13:48:05Z). It was outside #16395's declared surface, so it is still there.
The site
.github/workflows/ci.yml:1283, inside the dogfood: job (job header :1186, matrix shard: [1, 2, 3] at :1209):
pnpm turbo run test --filter=@objectstack/dogfood --log-order=stream -- --shard=${{ matrix.shard }}/3
The mechanism (already proven by #16395)
A run-level passthrough — everything after the bare -- — folds into the hash of every task in the run, not only the tasks that receive it. turbo.json on origin/main has:
"test": { "dependsOn": ["^build"] }
"build": { "dependsOn": ["^build"] }
so turbo run test --filter=@objectstack/dogfood pulls the package's whole upstream build closure into the run. packages/qa/dogfood/package.json declares 28 direct workspace dependencies (@objectstack/cli, core, spec, metadata, objectql, all the drivers, connectors, plugins and services, plus three example apps), so that closure is most of the repo.
With --shard=1/3, 2/3, 3/3 folded into all of those build hashes:
- each shard computes a different hash for the same
build output, so the three shards cannot share a single build;
- none of them can hit the ordinary
build cache that every other job in the workflow populates, because that cache was written with no passthrough in the hash.
The Restore Turbo cache step at :1243 already works around the symptom rather than fixing it — its key is shard-scoped, and the comment at :1236-1241 states the reason outright:
# Shard-scoped key: the turbo test hash differs per shard (pass-through …
That keeps a shard warm against its own history. It does nothing about the build closure being hashed three ways, and nothing about the shared build cache being unreachable.
Confirmation that no build precedes it
Steps in the dogfood job, in order, from origin/main:
1212 Checkout repository
1215 Setup Node.js
1220 Setup pnpm
1223 Get pnpm store directory
1228 Setup pnpm cache
1243 Restore Turbo cache
1253 Install dependencies
1269 Boot example apps and exercise real user flows <- contains :1283
There is no passthrough-free turbo run build anywhere ahead of the sharded run, and no --only on the run itself. Both halves of #16395's fix are absent.
Shape of the fix (same as #16395 / PR #16868)
- add a passthrough-free build step ahead of the run, so the closure is built once and hits the shared, content-addressed
build cache;
- add
--only to the sharded turbo run test, so the passthrough hash covers only the test task it is actually meant for.
Verification note
timeout-minutes: 30 at :1203 is the budget this defect is spending; the fix must not raise it — it is the instrument that would show the fix working. The measurable claim is the slice legs' Cached: N cached, M total.
Not claimed
I have not measured the current wall-clock cost per shard. The defect above is a static reading of origin/main; the size of the win is not part of the claim.
Filed unlabelled — triage owns domain:* and priority.
Generated by Claude Code
The Dogfood Regression Gate carries the same run-level Turbo passthrough defect that #16395 has just fixed in the
testjob (PR #16868, merged 2026-09-08T13:48:05Z). It was outside #16395's declared surface, so it is still there.The site
.github/workflows/ci.yml:1283, inside thedogfood:job (job header:1186, matrixshard: [1, 2, 3]at:1209):pnpm turbo run test --filter=@objectstack/dogfood --log-order=stream -- --shard=${{ matrix.shard }}/3The mechanism (already proven by #16395)
A run-level passthrough — everything after the bare
--— folds into the hash of every task in the run, not only the tasks that receive it.turbo.jsononorigin/mainhas:so
turbo run test --filter=@objectstack/dogfoodpulls the package's whole upstreambuildclosure into the run.packages/qa/dogfood/package.jsondeclares 28 direct workspace dependencies (@objectstack/cli,core,spec,metadata,objectql, all the drivers, connectors, plugins and services, plus three example apps), so that closure is most of the repo.With
--shard=1/3,2/3,3/3folded into all of thosebuildhashes:buildoutput, so the three shards cannot share a single build;buildcache that every other job in the workflow populates, because that cache was written with no passthrough in the hash.The
Restore Turbo cachestep at:1243already works around the symptom rather than fixing it — its key is shard-scoped, and the comment at:1236-1241states the reason outright:That keeps a shard warm against its own history. It does nothing about the build closure being hashed three ways, and nothing about the shared
buildcache being unreachable.Confirmation that no build precedes it
Steps in the
dogfoodjob, in order, fromorigin/main:There is no passthrough-free
turbo run buildanywhere ahead of the sharded run, and no--onlyon the run itself. Both halves of #16395's fix are absent.Shape of the fix (same as #16395 / PR #16868)
buildcache;--onlyto the shardedturbo run test, so the passthrough hash covers only thetesttask it is actually meant for.Verification note
timeout-minutes: 30at:1203is the budget this defect is spending; the fix must not raise it — it is the instrument that would show the fix working. The measurable claim is the slice legs'Cached: N cached, M total.Not claimed
I have not measured the current wall-clock cost per shard. The defect above is a static reading of
origin/main; the size of the win is not part of the claim.Filed unlabelled — triage owns
domain:*and priority.Generated by Claude Code