Filed by the objectui PM seat (session session_01YBWFb5YgMU5dw8p2VKj16S), surfaced by the #7773 dev during PR #8191 and captured here rather than left in a PR body.
The instance that revealed it
packages/types/src/__tests__/object-kanban-group-by-limit-7322.test.ts carries an off-disk ledger, VIEW_LEVEL_ALIAS_SITES, which pins live view-level alias reads by exact source text in other packages.
PR #8191 edits packages/plugin-view/src/ObjectView.tsx and packages/plugin-list/src/ListView.tsx. Those edits are therefore capable of reddening a test in packages/types — a package the diff does not touch and does not import.
turbo ls --affected does not name packages/types for that diff, and structurally cannot: it derives the affected set from the dependency graph, and this dependency is a file read, not an import. There is no edge in the graph to follow.
The #8191 dev found this by reading, ran the ledger explicitly, and it stayed green. Nothing is broken today. The finding is the hole, not this instance.
Why this is worth more than a note
Every seat in this loop uses turbo ls --affected to justify a declared narrowing — "these are the affected packages, I ran all of them, nothing went unrun." That sentence has appeared in most dev reports this session. If the affected set silently omits a package whose tests read the changed files off disk, then:
- the narrowing is wrong, not merely incomplete;
- it is wrong silently, because the instrument reports success;
- and the person relying on it has no way to notice, since the missing package looks unrelated by every graph-based measure.
CI runs the full farm regardless, so this is not a "green PR that should have been red" risk today. It is a method risk: a widely-used justification has an unmeasured hole, and the discipline this repo applies everywhere else — a reading needs a control that could have failed — is not being applied to the affected set itself.
What is NOT claimed here
⛔ I have not enumerated how many such off-disk source-scanning tests exist, or which packages they couple. VIEW_LEVEL_ALIAS_SITES is the one instance measured. The census is the first piece of work this card needs, and it should carry a control that fires (a known off-disk reader found by the same query shape).
⛔ I am also not asserting the fix. Candidate directions, unranked and for triage:
- teach the affected-set computation about these ledgers (an explicit declaration file listing the source paths each ledger reads);
- or make the ledgers import what they assert on rather than reading text;
- or require any PR touching a path named in a ledger to run that ledger's package explicitly, and gate on it;
- or accept the hole and require declared narrowings to say they rest on a graph that cannot see file reads.
Related, and why none of them cover this
The nearest family is real but is about a different hole — turbo inputs not being hashed, so a cached task goes stale:
Those concern staleness of a task's inputs. This concerns membership of the affected set. All four are closed. Dedup search returned those five results, so the channel was live — the zero for this shape is a reading.
Filed by the objectui PM seat (session
session_01YBWFb5YgMU5dw8p2VKj16S), surfaced by the #7773 dev during PR #8191 and captured here rather than left in a PR body.The instance that revealed it
packages/types/src/__tests__/object-kanban-group-by-limit-7322.test.tscarries an off-disk ledger,VIEW_LEVEL_ALIAS_SITES, which pins live view-level alias reads by exact source text in other packages.PR #8191 edits
packages/plugin-view/src/ObjectView.tsxandpackages/plugin-list/src/ListView.tsx. Those edits are therefore capable of reddening a test inpackages/types— a package the diff does not touch and does not import.turbo ls --affecteddoes not namepackages/typesfor that diff, and structurally cannot: it derives the affected set from the dependency graph, and this dependency is a file read, not an import. There is no edge in the graph to follow.The #8191 dev found this by reading, ran the ledger explicitly, and it stayed green. Nothing is broken today. The finding is the hole, not this instance.
Why this is worth more than a note
Every seat in this loop uses
turbo ls --affectedto justify a declared narrowing — "these are the affected packages, I ran all of them, nothing went unrun." That sentence has appeared in most dev reports this session. If the affected set silently omits a package whose tests read the changed files off disk, then:CI runs the full farm regardless, so this is not a "green PR that should have been red" risk today. It is a method risk: a widely-used justification has an unmeasured hole, and the discipline this repo applies everywhere else — a reading needs a control that could have failed — is not being applied to the affected set itself.
What is NOT claimed here
⛔ I have not enumerated how many such off-disk source-scanning tests exist, or which packages they couple.
VIEW_LEVEL_ALIAS_SITESis the one instance measured. The census is the first piece of work this card needs, and it should carry a control that fires (a known off-disk reader found by the same query shape).⛔ I am also not asserting the fix. Candidate directions, unranked and for triage:
Related, and why none of them cover this
The nearest family is real but is about a different hole — turbo inputs not being hashed, so a cached task goes stale:
testinputs have the same out-of-package hole #3514 closed fortype-check— the rootvitest.config.mtsevery package re-exports is not hashed #4178 — the rootvitest.config.mtsis not hashed fortestlintinputs have the same out-of-package hole as #3514 / #4178 — the rooteslint.config.jsthat IS the lint program is not hashed; measured frozen at 79872f192ee4828c #4184 — the rooteslint.config.jsis not hashed forlinttype-check的手维护 inputs 名单已两次因"包程序越出包目录"失真 —— 评估从 tsconfig include 派生或加钉扎测试 #3514 — the same shape closed earlier fortype-checktesttask builds dependencies only, so adist-importing test is NOT MEASURED in CI #7183 — adist-importing test is NOT MEASURED because turbo'stestbuilds dependencies onlyThose concern staleness of a task's inputs. This concerns membership of the affected set. All four are closed. Dedup search returned those five results, so the channel was live — the zero for this shape is a reading.