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

Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:l4srihhymu is past its budget: trevato/forge: "the decision ledger > stop is not the last word on a red check: the environment's fault runs it again, … #7840

Merged opened this

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

Merged

The test "stop is not the last word on a red check…" in `test/ledger.test.ts` now gives the same verdict whatever the check machine's load. I didn't reproduce the original red here, so the cause is inferred from the code. `bun test test/ledger.test.ts` passed 3 runs in a row (10/10) and `tsc --noEmit` is clean. I did not run the `scripts/gate.ts` or `scripts/fast.ts` steps.

shipped production is serving it deploy f9c1fcc

opened this

The test "stop is not the last word on a red check…" in test/ledger.test.ts now gives the same verdict whatever the check machine's load. I didn't reproduce the original red here, so the cause is inferred from the code. bun test test/ledger.test.ts passed 3 runs in a row (10/10) and tsc --noEmit is clean. I did not run the scripts/gate.ts or scripts/fast.ts steps.

Cause: The test started a real checks service (startChecks), so the "run it again" step actually cloned the repo and ran test -f OK.md inside a 60 s test timeout. On a loaded lane that run or checks.stop() could take longer than the timeout. The decision logic under test never needed a real check run.

Change: The test now installs a stand-in checks lane with provideChecksForTest. Its request queues a retry check run the way the real one does, and no check runs. Every assertion is unchanged:

  • The environment's fault gives reran, with one decision and no agent rework queued.
  • The same commit going red again gives reworked.

I removed the startChecks call, checks.stop() and the 60 s timeout.

Not done: I didn't change any code under src/. Real check execution has no coverage in this test, but test/merge-queue*.test.ts use the same stand-in approach.

To try: bun test test/ledger.test.ts. Once this lands, the sentinel cause shared:01m23vygyffx5hg2f5vm8r74sr:l4srihhymu should clear from the degraded list.

🤖 Generated with Claude Code

Closes #7819

commented

The test "stop is not the last word on a red check…" in test/ledger.test.ts now gives the same verdict whatever the check machine's load. I didn't reproduce the original red here, so the cause is inferred from the code. bun test test/ledger.test.ts passed 3 runs in a row (10/10) and tsc --noEmit is clean. I did not run the scripts/gate.ts or scripts/fast.ts steps.

Cause: The test started a real checks service (startChecks), so the "run it again" step actually cloned the repo and ran test -f OK.md inside a 60 s test timeout. On a loaded lane that run or checks.stop() could take longer than the timeout. The decision logic under test never needed a real check run.

Change: The test now installs a stand-in checks lane with provideChecksForTest. Its request queues a retry check run the way the real one does, and no check runs. Every assertion is unchanged:

  • The environment's fault gives reran, with one decision and no agent rework queued.
  • The same commit going red again gives reworked.

I removed the startChecks call, checks.stop() and the 60 s timeout.

Not done: I didn't change any code under src/. Real check execution has no coverage in this test, but test/merge-queue*.test.ts use the same stand-in approach.

To try: bun test test/ledger.test.ts. Once this lands, the sentinel cause shared:01m23vygyffx5hg2f5vm8r74sr:l4srihhymu should clear from the degraded list.

🤖 Generated with Claude Code

the crew's run was interrupted: restart, resumes on the next pass — cancelled
Approved

Test-only change, in line with the pipeline-first direction (a flaky, load-dependent test made deterministic). The stand-in lane uses provideChecksForTest exactly as merge-queue*.test.ts do. The retry run is queued with the same arguments the real request would use, and every assertion is unchanged. Two things I would do next: (1) the stand-in handle stays registered on the shared app after this test, so clear it in the finally block or confirm the later tests in this file do not depend on checksFor being unset; (2) keep one test somewhere that runs a real retry check end to end, since this file no longer does. No UI, security or tty surface is touched.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs