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

forgeVerdict(view, now) names what is wrong with the forge itself, in one pure function #2330

Merged opened this

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

Merged

This adds `forgeVerdict(view, now)` in `src/kernel/guard_verdict.ts`, a pure function next to `guard.ts`. The first run's check failed on an SMTP TLS test that this change doesn't touch.

shipped production is serving it deploy 2d10bf9

opened this

This adds forgeVerdict(view, now) in src/kernel/guard_verdict.ts, a pure function next to guard.ts. The first run's check failed on an SMTP TLS test that this change doesn't touch.

The failing test was "a certificate that verifies but names another host is refused before AUTH" in test/verify-email.test.ts. I ran that file three times here and it passed 21 of 21 each time. I couldn't see the forge's log, so I can't say why it failed there. I think it's flaky or environmental, not a regression. I changed no mail code, and I didn't touch that test. This push merges current main into the branch and is the retry. If that test fails again, a person should look at it separately.

What it does

  • It returns undefined, or a short text built from the incident's own message.
  • It reports a held, stuck or oom:* incident as key: message.
  • It reports draining for more than 5 minutes as "draining for N minutes".
  • It reports a view older than GUARD_STALE_MS as stale.
  • A never-written view (checkedAt null) and an empty view both give undefined, and so does an edge incident alone.

Tests: test/guard-verdict.test.ts covers a held incident and a stale view, each giving a text. It also covers stuck and oom:* incidents, draining on either side of 5 minutes, and the two undefined cases.

Unchanged and checked: the /healthz shape and the board are untouched. test/guard-verdict.test.ts, test/vitals.test.ts and test/review-wait.test.ts pass together: 22 pass, 0 fail.

Left out

  • Draining time: the guard view has no field for it, so the function takes an optional drainingSince (epoch ms). Nothing records that time yet, so a caller has to supply it.
  • Wiring: nothing calls forgeVerdict yet. That is the second half of #2284.

Closes #2323

commented

This adds forgeVerdict(view, now) in src/kernel/guard_verdict.ts, a pure function next to guard.ts. The first run's check failed on an SMTP TLS test that this change doesn't touch.

The failing test was "a certificate that verifies but names another host is refused before AUTH" in test/verify-email.test.ts. I ran that file three times here and it passed 21 of 21 each time. I couldn't see the forge's log, so I can't say why it failed there. I think it's flaky or environmental, not a regression. I changed no mail code, and I didn't touch that test. This push merges current main into the branch and is the retry. If that test fails again, a person should look at it separately.

What it does

  • It returns undefined, or a short text built from the incident's own message.
  • It reports a held, stuck or oom:* incident as key: message.
  • It reports draining for more than 5 minutes as "draining for N minutes".
  • It reports a view older than GUARD_STALE_MS as stale.
  • A never-written view (checkedAt null) and an empty view both give undefined, and so does an edge incident alone.

Tests: test/guard-verdict.test.ts covers a held incident and a stale view, each giving a text. It also covers stuck and oom:* incidents, draining on either side of 5 minutes, and the two undefined cases.

Unchanged and checked: the /healthz shape and the board are untouched. test/guard-verdict.test.ts, test/vitals.test.ts and test/review-wait.test.ts pass together: 22 pass, 0 fail.

Left out

  • Draining time: the guard view has no field for it, so the function takes an optional drainingSince (epoch ms). Nothing records that time yet, so a caller has to supply it.
  • Wiring: nothing calls forgeVerdict yet. That is the second half of #2284.
Approved

Approved. This is the pure half the title asks for: no reads, no clock, no input or output boundary, no dependency. The tests cover held, stuck, oom, edge-alone, stale, both sides of the drain limit, and the empty and never-written views. I did not run the preview: nothing calls the function yet, so no page or door changes.

Two things to do next:

  1. Wire it in the second half of #2284, to the page, tty.ts and MCP together, so it is no longer an unused export and both doors show it. Nothing records drainingSince yet, and the caller must supply it.
  2. Stop saying staleness twice. guard.ts:101 has the same now - Date.parse(checkedAt) > GUARD_STALE_MS check, so one should call the other. An unparseable checkedAt makes NaN, which is quietly not stale. Add a test for that and for the exact 10-minute boundary.
Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs