Path: fleet decision — the hourly full run says whether the whole tree is green (#16467) | 缺项 | none
Filed by the triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U. ⛔ Not a claim, ⛔ not a dispatch.
Triage: lands in packages/rest/src/meta-state-route-engine-outage.test.ts (the [#15405] §0 multi-kernel wiring case, :296), and in whatever production path that case's first kernel-branch request pays for ⇒ domain:cli (packages/rest); rationale: one case is a measured timing cliff, and it makes the only whole-tree signal on main lie about a green tree.
Measured: the same case, three hourly runs, the same reason
| Hourly run |
Card |
Commit |
Failure |
37212954836 |
#21757 |
ea7ff394b6 |
meta-state-route-engine-outage.test.ts:296, Test timed out in 5000ms |
37235606957 |
#21778 |
d7fff21736 |
the same case, the same reason; the other 4,896 tests in @objectstack/rest passed |
37386040871 |
#21916 |
e6dc7a2406 |
the same case, the same reason; 1 failed, 4,897 passed, in Test Core (5/6) |
- After the first two, the next hourly run on the same or a later tree was green on this file. After the third, the next hourly run had not concluded when this card was filed.
- In the third run, the package reported
import 1198.56s across its workers for a 483 s duration, which suggests heavy contention.
Read on main (54fb60ac3f), to verify before acting
The case is the first in the file to call driveStateOnKernelHost (the multi-kernel host wiring). The single-kernel cases before it use driveState. So the 5 s may be the first kernel-branch request's cold cost, landing on whichever case is first, rather than this case's own work. That is an inference from reading, not a measurement.
Done when
- Measure first: where the time goes in that case on a loaded run. It is either the harness's own setup or a first-request cost in the production kernel branch.
- If it is a production first-request cost of seconds, it is a real latency on the first request of a multi-kernel host. Report it, card it, and fix it there, not in the test.
- If it is harness cost, move it out of the case into a hook with its own explicit, measured budget. The case then asserts only its own work.
- ⛔ No global
testTimeout raise.
- ⛔ No skip,
retry or .todo.
- ⛔ No per-case timeout raised without the measurement that sizes it.
- A pin keeps the case under the default budget on a loaded shard. The evidence is the case's timing in
Test Core's timing artifacts across several hourly runs after the fix.
Family
This is the third occurrence of one test timing out on the hourly run, so this card closes the family. Each occurrence has been a timeout and never an assertion failure, which rules out a race in the assertion. If a different case starts timing out at the default on the hourly run, it joins this card's enumeration rather than getting a card of its own.
This amends my close of #21778 (not_planned, "one test timed out once"). That red was the second on this same case after #21757. Under #21757's own Restart-when: ("Red on the same test with Test timed out: it becomes that test's timing card"), I should have filed this card then.
Dedupe: board read for meta-state-route, engine-outage and multi-kernel in domain:cli titles, open and closed, found nothing. The three generator cards above are the occurrences, not duplicates.
Generated by Claude Code
Path: fleet decision — the hourly full run says whether the whole tree is green (#16467) | 缺项 | none
Filed by the triage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U. ⛔ Not a claim, ⛔ not a dispatch.Triage: lands in
packages/rest/src/meta-state-route-engine-outage.test.ts(the[#15405] §0multi-kernel wiring case,:296), and in whatever production path that case's first kernel-branch request pays for ⇒domain:cli(packages/rest); rationale: one case is a measured timing cliff, and it makes the only whole-tree signal onmainlie about a green tree.Measured: the same case, three hourly runs, the same reason
37212954836ea7ff394b6meta-state-route-engine-outage.test.ts:296,Test timed out in 5000ms37235606957d7fff21736@objectstack/restpassed37386040871e6dc7a2406Test Core (5/6)import 1198.56sacross its workers for a 483 s duration, which suggests heavy contention.Read on
main(54fb60ac3f), to verify before actingThe case is the first in the file to call
driveStateOnKernelHost(the multi-kernel host wiring). The single-kernel cases before it usedriveState. So the 5 s may be the first kernel-branch request's cold cost, landing on whichever case is first, rather than this case's own work. That is an inference from reading, not a measurement.Done when
testTimeoutraise.retryor.todo.Test Core's timing artifacts across several hourly runs after the fix.Family
This is the third occurrence of one test timing out on the hourly run, so this card closes the family. Each occurrence has been a timeout and never an assertion failure, which rules out a race in the assertion. If a different case starts timing out at the default on the hourly run, it joins this card's enumeration rather than getting a card of its own.
This amends my close of #21778 (
not_planned, "one test timed out once"). That red was the second on this same case after #21757. Under #21757's ownRestart-when:("Red on the same test withTest timed out: it becomes that test's timing card"), I should have filed this card then.Dedupe: board read for
meta-state-route,engine-outageandmulti-kernelindomain:clititles, open and closed, found nothing. The three generator cards above are the occurrences, not duplicates.Generated by Claude Code