Skip to content

test(rest): meta-state-route-engine-outage.test.ts's multi-kernel wiring case times out at vitest's 5000 ms default under the hourly full run, and has turned main's hourly run red three times in two days #21920

Description

@objectstack-fleet

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

Activity

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

Metadata

Metadata

Assignees

Labels

area:devpathThe road — create, dev, verify, publish/install, connect an agent, iteratebugSomething isn't workingdomain:clipriority:p2Medium: important, M3tests

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions