Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:1ga9w5ebpp is past its budget: trevato/forge: "event audience coverage > every kind the source emits is classified" failed on 3 pulls in the last hour… #3817

This is a guess at the cause, not a confirmed fix. I couldn't reproduce the failure: the test passes here (4 pass, about 100 ms), and src/ already classifies every kind it emits.

The scan listed src/*/.ts relative to the working directory, so a runner started from anywhere other than the repository root would find no sources. It also ran under bun's default 5-second timeout, which a loaded check machine could exceed. I made two changes in test/event-audience-coverage.test.ts:

• Scan root: the scan now anchors at the repository, using import.meta.dir, so the working directory no longer matters.
• Timeout: the main coverage test now has a 60-second timeout, so machine load can't decide its verdict.

The classification logic and the scan itself are unchanged, and the other three tests in the file are unchanged.

To try it, run bun test test/event-audience-coverage.test.ts from the repository root or from another directory.

If the red persists, the cause was something else. The likeliest candidate is a pull that adds a new event kind without classifying it in src/core/event_audience.ts. In that case the failure is real for that pull, and I'd want the forge check's log to see which kind it names.

Closes #3723

This is a guess at the cause, not a confirmed fix. I couldn't reproduce the failure: the test passes here (4 pass, about 100 ms), and src/ already classifies every kind it emits.

The scan listed src/*/.ts relative to the working directory, so a runner started from anywhere other than the repository root would find no sources. It also ran under bun's default 5-second timeout, which a loaded check machine could exceed. I made two changes in test/event-audience-coverage.test.ts:

• Scan root: the scan now anchors at the repository, using import.meta.dir, so the working directory no longer matters.
• Timeout: the main coverage test now has a 60-second timeout, so machine load can't decide its verdict.

The classification logic and the scan itself are unchanged, and the other three tests in the file are unchanged.

To try it, run bun test test/event-audience-coverage.test.ts from the repository root or from another directory.

If the red persists, the cause was something else. The likeliest candidate is a pull that adds a new event kind without classifying it in src/core/event_audience.ts. In that case the failure is real for that pull, and I'd want the forge check's log to see which kind it names.

The fix is already pushed. I have no further change to make, and I still can't confirm it resolves the failure.

• What I changed: in test/event-audience-coverage.test.ts, the scan now reads src/ from the repository root instead of the runner's working directory. The main coverage test also gets a 60-second timeout instead of bun's 5-second default.
• What I couldn't do: reproduce the failure. The test passes here in about 100 ms, and every event kind in src/ is classified on current main.
• What the pulls show: I looked at checks on the open pulls. None of the check logs I could reach shows this test failing. One failure is a type error (Type 'undefined' is not assignable to type 'Html') on 3820 and 3818. A full check on 3817 took 261 seconds, so a loaded check machine making the old 5-second limit unreliable is plausible.
• If the sentinel is still red after the next green check on main: the cause is something else. The likeliest is a pull adding an event kind without classifying it in src/core/event_audience.ts. I'd need the failing check's log to see which kind it names.