Failing job: test specs (1/2) debug linux-aarch64
Run URLs:
Both are independent merges to main, neither touching upgrade code, about 3.5 hours apart. Every sibling job in each run passed. Only this job failed, both times on the same test.
Failing test: specs::upgrade::stable (tests/specs/upgrade/stable/__test__.jsonc). Same "pattern match failed" panic both times.
Classification: Flaky, and probably already known. The test spec already marks the upgrade --force step as "flaky": true:
So this isn't really a new discovery. It's more evidence that whatever retry logic the "flaky": true marker gives this step isn't catching everything. It still produced two hard CI failures in ordinary history, on commits unrelated to upgrade logic.
Hypothesis: the step downloads a real release over the network, so it's probably just release-server latency or a runner network blip. Not confirmed, just the obvious explanation given the step is already flagged as network-dependent.
How I found this: flakelens, a tool that correlates isolated job failures (siblings in the same run pass) across unrelated commits in ordinary GitHub Actions history. It pulled both run logs and confirmed the same test failed each time before I posted this. Flagging in case it's useful, happy to hear if it's already tracked elsewhere.
Failing job:
test specs (1/2) debug linux-aarch64Run URLs:
Both are independent merges to
main, neither touching upgrade code, about 3.5 hours apart. Every sibling job in each run passed. Only this job failed, both times on the same test.Failing test:
specs::upgrade::stable(tests/specs/upgrade/stable/__test__.jsonc). Same "pattern match failed" panic both times.Classification: Flaky, and probably already known. The test spec already marks the
upgrade --forcestep as"flaky": true:{ "commandName": "./deno_copy", "args": "upgrade --force", "output": "upgrade.out", "exitCode": 0, "flaky": true }So this isn't really a new discovery. It's more evidence that whatever retry logic the
"flaky": truemarker gives this step isn't catching everything. It still produced two hard CI failures in ordinary history, on commits unrelated to upgrade logic.Hypothesis: the step downloads a real release over the network, so it's probably just release-server latency or a runner network blip. Not confirmed, just the obvious explanation given the step is already flagged as network-dependent.
How I found this: flakelens, a tool that correlates isolated job failures (siblings in the same run pass) across unrelated commits in ordinary GitHub Actions history. It pulled both run logs and confirmed the same test failed each time before I posted this. Flagging in case it's useful, happy to hear if it's already tracked elsewhere.