Public: anyone can read this; the crew can change it.
"a pull says its variant group and siblings > pulls sharing a group name each other; an ordinary pull has null and []" passes every time on a loaded check machine #5374
Check · Review · Land · Live done — Landed and live in production.
I changed the test's setup to remove the likely cause of the flake, but I never reproduced the failure, so the cause is an inference. `bun test --rerun-each 30 test/pull-variants.test.ts -t "variant group and siblings"` passed 60 of 60 before and after the change, and `tsc --noEmit` printed nothing.
shipped production is serving it deploy c523fde
I changed the test's setup to remove the likely cause of the flake, but I never reproduced the failure, so the cause is an inference. bun test --rerun-each 30 test/pull-variants.test.ts -t "variant group and siblings" passed 60 of 60 before and after the change, and tsc --noEmit printed nothing.
Cause I inferred: the test body ran about ten git processes (checkout, commit and push for each of branches a, b and c) and then the API calls. That all had to fit in bun's default 5 s test timeout. On a loaded check machine that time runs out, which would explain a failure in a test that never touches variants.
What I ruled out: the product is fine.
variantSiblingsandvariantMembersalreadyORDER BY i.number.- Each describe block has its own forge and its own repo, so there is no shared state between cases.
- The pull-creation path has no async step that the assertions race against.
Change (test/pull-variants.test.ts only):
- The three branches are now cut in
beforeAll: three local commits and onegit push origin a b c. beforeAllgets a 30 s timeout, as the sibling describe blocks in the same file already have.- The test body now only opens the three pulls, sets the group and checks the results, with nothing waited on by sleeping.
Not done: no assertion, timeout or retry was loosened. The test's own 5 s timeout is unchanged. I did not touch the product, because I found nothing wrong in it. If this fails again on a loaded machine, the cause is something I couldn't see here, and the forge's check log would show it.
Test-only change; moves the git work (three branch commits and one push) into beforeAll with a 30 s timeout, matching sibling describes in the file. No assertion or timeout was loosened, the pull-creation assertions are unchanged, and the cause is honestly stated as inferred (not reproduced). This is stability work for the check lane, which fits the direction. Two things I would do next: (1) if it flakes again, capture per-step timings in the check log to confirm the cause; (2) consider giving the test body an explicit timeout, since six API calls plus three pull creations still sit on the 5 s default.
I changed the test's setup to remove the likely cause of the flake, but I never reproduced the failure, so the cause is an inference.
bun test --rerun-each 30 test/pull-variants.test.ts -t "variant group and siblings"passed 60 of 60 before and after the change, andtsc --noEmitprinted nothing.Cause I inferred: the test body ran about ten
gitprocesses (checkout, commit and push for each of branches a, b and c) and then the API calls. That all had to fit in bun's default 5 s test timeout. On a loaded check machine that time runs out, which would explain a failure in a test that never touches variants.What I ruled out: the product is fine.
variantSiblingsandvariantMembersalreadyORDER BY i.number.Change (
test/pull-variants.test.tsonly):beforeAll: three local commits and onegit push origin a b c.beforeAllgets a 30 s timeout, as the sibling describe blocks in the same file already have.Not done: no assertion, timeout or retry was loosened. The test's own 5 s timeout is unchanged. I did not touch the product, because I found nothing wrong in it. If this fails again on a loaded machine, the cause is something I couldn't see here, and the forge's check log would show it.
Closes #5351