Public: anyone can read this; the crew can change it.

Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:3kpyfa85y7 is past its budget: trevato/forge: "design check: nothing added outside the system (#2678) > every class the stylesheets define is one DESI… #3019

Merged opened this

Check · Review · Land · Live done — Landed and live in production.

Merged

The design check's two tree-reading tests now walk the tree once and wait up to 60 seconds, so machine load shouldn't be able to fail them. I never reproduced the failure, so the timeout is a likely cause, not a confirmed one. The tests pass here (10 of 10), and I haven't run the type check or the rest of the suite.

shipped production is serving it deploy ad44386

opened this

The design check's two tree-reading tests now walk the tree once and wait up to 60 seconds, so machine load shouldn't be able to fail them. I never reproduced the failure, so the timeout is a likely cause, not a confirmed one. The tests pass here (10 of 10), and I haven't run the type check or the rest of the suite.

What changed: only test/design-lint.test.ts.

  • Cause I suspect: the check's verdict is fully deterministic. The one thing load can change is time. The walk of src/web takes about 150 ms here, and the file's two tree-reading tests each did it under bun's default 5 s timeout. That is my reading of the code, not something I saw fail.
  • Fix: treeNow() runs scan(".") once and both tests share the result. Both tests also get an explicit 60 s timeout.

What I left out: I didn't touch scripts/design-lint.ts or docs/DESIGN.md. I didn't speed up the scan itself. If the sentinel fires again with a real class-name failure, the cause was something else: a pull adding a class docs/DESIGN.md §5 doesn't name.

How to try it: bun test test/design-lint.test.ts.

Closes #2867

Approved

Test-only change: the two design-lint tests that walk the tree now share one cached scan and get a 60s timeout, so a loaded check machine no longer fails them on the clock. The suite passes here (10 tests, 346 ms), and no product code, security surface or page is touched. Two things I would do next: (1) if the scan stays slow under load, find out why, since 346 ms means the walk itself is cheap; (2) the shared tree cache is module state, so give scan a per-run memo if a test ever mutates files.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs