Public: anyone can read this; the crew can change it.
Sentinel: red:01m23vygyffx5hg2f5vm8r74sr is past its budget: trevato/forge: main is red at 931899b — "a private repository is linked only to who may read it" fails; 1 pull check wa… #6284
Check · Review · Land · Live done — Landed and live in production.
I fixed the flaky test "a private repository is linked only to who may read it" by changing only the test (`test/apps-door.test.ts`); `src/` is untouched. I couldn't reproduce the failure here, so I haven't confirmed the fix against it.
shipped production is serving it deploy b2c98db
I fixed the flaky test "a private repository is linked only to who may read it" by changing only the test (test/apps-door.test.ts); src/ is untouched. I couldn't reproduce the failure here, so I haven't confirmed the fix against it.
What was wrong: the test expected the door to say "secret plan · check running". It never created a run for that pull. The line came from the runtime's own preview deploy of the fake head x. That deploy starts as "running" and then fails, because commit x doesn't exist. The door words the pull's newest run, so on a slower or busier machine the line read "check red" and the test failed. It passed every time on this machine, so main went red only under the forge's load.
What changed: the test now inserts its own check run for that head in the running state. Its id is zzzz-pinned, which sorts after every real run id, so it stays the newest run whatever the preview deploy does.
Checks: test/apps-door.test.ts passed 12/12 on three runs before the change and on two runs after it. I didn't finish a full bun test here; it ran past the 10-minute limit, and its sandbox-blocked network calls made the run unrepresentative. bun x tsc --noEmit couldn't load the bun types in this sandbox, so the type check didn't run.
Not done: I left alone the underlying race, where a pull whose head the runtime can't deploy shows a briefly changing check word. That is how the door is meant to behave.
To try: bun test test/apps-door.test.ts. Once the forge's check passes, red:01m23vygyffx5hg2f5vm8r74sr should leave the degraded list.
Test-only fix, 7 lines, no src or UI change, so nothing on the phone/keyboard/no-JS side to review. The diagnosis holds: src/apps/door_pulls.ts:33-35 words the newest deploy/check run by ORDER BY id DESC, and the test never made one. It leaned on the preview deploy racing from running to failed. The pinned zzzz-pinned id sorts after every real id, and running maps to "check running". The columns inserted match the run schema. Two next steps: (1) if a stale-run reaper could ever touch a running check row in this harness, set started_at or assert the word in a loop to prove it stays pinned; (2) add a second assertion that a failed newest run reads "check red", so the word mapping is covered deterministically instead of by the race.
The full gate on land was red; the pull is open again. Red tests:
- a plan of 2,000 closed and 300 open issues, 3,000 pulls and 1,500 runs reads in under 50 ms with the same limbs
- a plan of 2,000 closed and 300 open issues, 3,000 pulls and 1,500 runs reads in under 50 ms with the same limbs [488.12ms] [shard 411]
Red on top of #6279, #6281, which landed first from the same merge-queue candidate: red on its own on that base, or only together with them. Bring this pull up to date with the base and push.
The branch is merged up to date with origin/main and pushed. The merge was clean, and the forge's check hasn't run on the new push yet.
- Fix: the change is still only in
test/apps-door.test.ts. The test pins its own running check run for the pull's head, so it no longer depends on the preview deploy failing at some unpredictable moment. - The red test trevato named: the "2,000 closed and 300 open issues… under 50 ms" test is in
test/milestones-shape.test.ts. It was timed out at 488 ms in a shard where other work was running. This pull doesn't touch milestones code, so the test looks like a load-sensitive timing case. After the merge it passed here together withtest/apps-door.test.ts: 15 pass, 0 fail. I didn't change that test. If it fails again after this push, it needs its own issue. - Reviewer suggestions: I didn't add a second test asserting that a failed newest run reads "check red", or anything for a stale-run reaper touching the pinned row.
checkWord's mapping isn't covered by this pull. - To try:
bun test test/apps-door.test.ts.
Test-only fix, src/ untouched, and it matches the cause. The door words the newest run by id (ORDER BY id DESC), and the pinned run (kind check is allowed since migration 0017, state running, same head x) sorts last, so "check running" no longer depends on the preview deploy racing to fail. There is no UI in this change to check in the preview. The two things I would do next: (1) the milestones 50 ms timing test that tripped the merge queue (test/milestones-shape.test.ts) is load-sensitive and needs its own issue if it recurs; (2) add a small checkWord test that a newest failed run on the head reads "check red", so the mapping the old flake exposed is covered.
I fixed the flaky test "a private repository is linked only to who may read it" by changing only the test (
test/apps-door.test.ts);src/is untouched. I couldn't reproduce the failure here, so I haven't confirmed the fix against it.What was wrong: the test expected the door to say "secret plan · check running". It never created a run for that pull. The line came from the runtime's own preview deploy of the fake head
x. That deploy starts as "running" and then fails, because commitxdoesn't exist. The door words the pull's newest run, so on a slower or busier machine the line read "check red" and the test failed. It passed every time on this machine, so main went red only under the forge's load.What changed: the test now inserts its own
checkrun for that head in therunningstate. Its id iszzzz-pinned, which sorts after every real run id, so it stays the newest run whatever the preview deploy does.Checks:
test/apps-door.test.tspassed 12/12 on three runs before the change and on two runs after it. I didn't finish a fullbun testhere; it ran past the 10-minute limit, and its sandbox-blocked network calls made the run unrepresentative.bun x tsc --noEmitcouldn't load thebuntypes in this sandbox, so the type check didn't run.Not done: I left alone the underlying race, where a pull whose head the runtime can't deploy shows a briefly changing check word. That is how the door is meant to behave.
To try:
bun test test/apps-door.test.ts. Once the forge's check passes,red:01m23vygyffx5hg2f5vm8r74srshould leave the degraded list.Closes #6282