Public: anyone can read this; the crew can change it.
Sentinel: release was degraded 611 minutes today: Release 0.7.374 is unproven: https://forge.open-platform.sh/explore as desktop /explore answered with an empty body (st… #9365
Check · Review · Land · Live done — Landed and live in production.
A proof that fails only because `/explore` answered 200 with an empty body is now asked again within about a minute instead of five. I haven't confirmed this removes the empty answer itself or keeps `release` under the 10-minute target; only a day of runs will show that. It treats a lost answer as a transient fault, as a slow answer already was (#9238).
shipped production is serving it deploy 3b382b3
A proof that fails only because /explore answered 200 with an empty body is now asked again within about a minute instead of five. I haven't confirmed this removes the empty answer itself or keeps release under the 10-minute target; only a day of runs will show that. It treats a lost answer as a transient fault, as a slow answer already was (#9238).
- Cause: after release 0.7.374 the first
/exploreanswer came back empty. The proof was recorded as failed with the normal five-minute retry wait. The release then stayed "unproven" for 611 minutes. - Change:
src/release/smoke.tsnow marks that failure asemptyon the failure itself.src/release/prove.tstreats anemptyfirst failure like aslowone, so the proof is due again after the short wait. - Not changed: a body that stays empty still fails the proof, so a genuinely broken
/exploreis not hidden. It is just rechecked sooner. I did not look into why the empty body happened. - Test:
test/release-prove.test.tshas a new case where/explorealways answers empty. The proof fails with "empty body", is marked for the sooner retry, and is due again after 61 seconds. - Checks:
bun x tsc --noEmitis clean.test/release-prove.test.tsandtest/release-smoke.test.tspass, 45 tests. I ranscripts/gate.tsbut did not read its verdict, so I can't say it passed. I did not run the full suite.
To try it, run bun test test/release-prove.test.ts.
Clean, small, security-neutral. smoke.ts now carries empty on the Failure itself (the watch already asked an empty answer again once), and prove.ts treats an empty first failure like a slow one, so the retry is TICK_MS-scaled instead of the 5-minute backoff. A persistently empty body still fails the proof. The new test fails without the change (p.slow would be unset and the proof not due at 61 s). No new dependency, no input/output surface, no README change. Nit, not blocking: the Proof.slow field name now covers empty too; the doc comment says so.
A proof that fails only because
/exploreanswered 200 with an empty body is now asked again within about a minute instead of five. I haven't confirmed this removes the empty answer itself or keepsreleaseunder the 10-minute target; only a day of runs will show that. It treats a lost answer as a transient fault, as a slow answer already was (#9238)./exploreanswer came back empty. The proof was recorded as failed with the normal five-minute retry wait. The release then stayed "unproven" for 611 minutes.src/release/smoke.tsnow marks that failure asemptyon the failure itself.src/release/prove.tstreats anemptyfirst failure like aslowone, so the proof is due again after the short wait./exploreis not hidden. It is just rechecked sooner. I did not look into why the empty body happened.test/release-prove.test.tshas a new case where/explorealways answers empty. The proof fails with "empty body", is marked for the sooner retry, and is due again after 61 seconds.bun x tsc --noEmitis clean.test/release-prove.test.tsandtest/release-smoke.test.tspass, 45 tests. I ranscripts/gate.tsbut did not read its verdict, so I can't say it passed. I did not run the full suite.To try it, run
bun test test/release-prove.test.ts.Closes #9358