Skip to content

CI: Dogfood Regression Gate has the same run-level Turbo passthrough defect fixed by #16395 #16886

Description

@claude

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)

  1. add a passthrough-free build step ahead of the run, so the closure is built once and hits the shared, content-addressed build cache;
  2. 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions