Skip to content

Retry Bun backtest cells on hosted-fetch 5xx blips - #1244

Merged
Mikola Lysenko (mikolalysenko) merged 5 commits into
mainfrom
ci-janitor/bun-backtest-http-5xx
Oct 9, 2026
Merged

Mikola Lysenko (mikolalysenko) merged 5 commits into
mainfrom
ci-janitor/bun-backtest-http-5xx

Conversation

@mikolalysenko

@mikolalysenko Mikola Lysenko (mikolalysenko) commented Oct 9, 2026 •

Copy link
Copy Markdown
Collaborator

Problem

Bun patch compatibility went red on main in push run 37852649519 (6ab9e43). All four bun.lockb legs (native (ubuntu-latest, 0.8.1 / 1.0.0 / 1.0.36 / 1.1.0)) failed the same cell at the same moment:

0.8.1 vendored-then-hosted vendored FAIL ['frozenPatchedBytes', 'ordinaryPatchedBytes'] HTTP Error 503: Service Unavailable
bun 0.8.1: 37/38 passed, 34 supported, 4 unsupported

The text-lock legs and the next main pushes were green, so this was a short patch.socket.dev blip. The harness's fresh-cell retry (retry_network_cell) exists for exactly this, but it never fired, because the row didn't look like a transport failure.

Root cause

has_transport_failure only recognizes the CLI's request errors / patch API 5xx, and bun's error: GET <url> - 5xx lines. Two things in this cell fell outside that:

  1. The harness's own fetch. On bun.lockb origins the hosted path calls hosted_lockb_digest(), which reads the patched tarball from patch.socket.dev with a bare urlopen. A 503 there raises HTTPError, and row['error'] becomes HTTP Error 503: Service Unavailable. That's urllib's wording, so neither regex matches it. This is the only harness urlopen without a retry, and the cell took 7 s, so it wasn't published_record's 5× backoff.
  2. The labelled installs. The cold frozen / ordinary installs failed in the same window, but their output (where bun prints its own fetch failure) was thrown away (code, _ = install(...)). The VEX checkout install already keeps it (row['vexInstallTransport'], "kept so a fetch failure here qualifies the cell for a retry"), but these four installs didn't.

Fix

scripts/backtest-bun.py only:

  • Add HARNESS_TRANSPORT_FAILURE, which matches urllib's HTTP Error 5xx / HTTP Error 429 and <urlopen error …> (no response), to has_transport_failure. 4xx and functional failures are still final on the first attempt.
  • Record row[label + 'InstallTransport'] = bun_transport_failures(output) for the frozen / ordinary / warmFrozen / warmOrdinary installs, the same pattern as vexInstallTransport.

I deliberately didn't add an inner retry to hosted_lockb_digest. It would hide the evidence while the install checks of the same cell stay red. A fresh-cell retry re-proves the whole cell from a clean tree.

Proof

  • Before the fix, has_transport_failure({'error': 'HTTP Error 503: Service Unavailable'}) returns False, which is why the cell never retried. After the fix it returns True.
  • New tests in scripts/tests/test_backtest_harnesses.py:
    • urllib 503 / 429 / <urlopen error> count as transport failures, and 404 doesn't.
    • A row carrying a failed install's error: GET … - 503 line counts as a transport failure, and a clean install doesn't.
    • A cell that first fails with HTTP Error 503 is retried fresh and passes, with the failed attempt's checks recorded.
  • python3 -m unittest scripts/tests/test_backtest_harnesses.py: 78 tests OK (75 before). The Bun retry test class passed 50/50 in a loop.
  • Not run: a real Bun backtest against a 503ing patch.socket.dev. This PR's own Bun patch compatibility run exercises the changed harness end to end.

Where tests run

Nothing removed or moved. The harness unit tests run in every compatibility workflow's python3 -m unittest scripts/tests/test_backtest_harnesses.py step. The Bun matrix runs on PRs that touch it and on every main push.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KTF5Q8WeZfwTw6EyQrGorh


Generated by Claude Code

Bun patch compatibility went red on main in run 37852649519: all
four bun.lockb legs (0.8.1, 1.0.0, 1.0.36, 1.1.0) failed the same
vendored-then-hosted cell at the same moment with "HTTP Error 503:
Service Unavailable" while patch.socket.dev blipped. The cell has a
fresh-tree retry for transport failures, but it never fired:

- the 503 came from hosted_lockb_digest's own urllib fetch, and
  urllib's "HTTP Error 5xx" / "<urlopen error ...>" text matched
  neither the CLI's nor bun's transport patterns;
- the cold frozen/ordinary installs that failed in the same window
  kept bun's own "error: GET <url> - 503" line only in their logs,
  never on the row has_transport_failure inspects.

Classify urllib 5xx/429/no-response errors as transport failures,
and record each labelled install's bun transport lines on the row,
as the VEX checkout install already does. Functional failures and
4xx responses still fail on the first attempt.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KTF5Q8WeZfwTw6EyQrGorh
@mikolalysenko Mikola Lysenko (mikolalysenko) added the ci-janitor Opened by the CI janitor routine (flakes, redundant tests, CI perf) label Oct 9, 2026
@mikolalysenko

Copy link
Copy Markdown
Collaborator Author

bugbot run


Generated by Claude Code

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

Reviewed by Cursor Bugbot for commit 8d3d4e1. Configure here.

@mikolalysenko

Copy link
Copy Markdown
Collaborator Author

Ready for review (burn-down agent).

  • Head: 8d3d4e1
  • CI: 242/242 green (233 success, 9 skipped)
  • Bugbot: reviewed 8d3d4e1, no findings
  • Mergeable, no CHANGELOG.md changes.

Generated by Claude Code

@mikolalysenko

Copy link
Copy Markdown
Collaborator Author

Final review brief

What it does: Adds a HARNESS_TRANSPORT_FAILURE regex (urllib HTTP Error 5xx/429 or <urlopen error) to the Bun backtest harness, so a cell whose hosted_lockb_digest fetch hit a 503 goes to the existing fresh-cell retry (retry_network_cell, 3 attempts). It also keeps bun's fetch-error lines from the frozen/ordinary/warm installs in the row, the same way the VEX install already does.

Risk: low. CI harness only. A retry starts a fresh cell and is capped at 3 attempts; the last attempt's result is final, so a real failure still goes red. 4xx (e.g. 404) is excluded and tested.

Look here:

Verified: read the full diff; retry_network_cell returns on pass, on no transport failure, or on the last attempt, so nothing is masked. python3 -m unittest scripts/tests/test_backtest_harnesses.py: 78 OK (BunTransportRetryTests 7 OK). CI 242/242 green on 8d3d4e1 (ci-ok, clippy). Bugbot: no findings on this head. No CHANGELOG.md change, no open threads.

Changes I made: none.

Open questions (non-blocking): a read timeout inside response.read() or RemoteDisconnected still won't match the regex, so those cells won't retry. That's outside the PR's stated scope; a follow-up could match on exception type.

Auto-merge is armed: approving sends this straight to the merge queue.


Generated by Claude Code

@mikolalysenko
Mikola Lysenko (mikolalysenko) added this pull request to the merge queue Oct 9, 2026
#1009 landed its own HARNESS_TRANSPORT_FAILURE in backtest-bun.py
after this branch was queued. The squash merged cleanly, but the
later assignment shadowed this PR's HTTP 5xx/429 pattern, so
BunTransportRetryTests failed in merge group 87ff737 and every
group stacked behind it.

Keep one definition: the urllib 5xx/429 match plus #1009's anchored
urlopen and Errno connection-reset matches.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LVVtQNBuPeYaRmV82s6r6V
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Oct 9, 2026
@mikolalysenko

Copy link
Copy Markdown
Collaborator Author

Evicted from the merge queue: semantic conflict with #1009 (merged 13:21 UTC).

Both PRs added HARNESS_TRANSPORT_FAILURE to scripts/backtest-bun.py. The squash merged cleanly, but #1009's later assignment shadowed this PR's HTTP Error 5xx/429 pattern. As a result, lint-ecosystems failed BunTransportRetryTests.test_a_harness_fetch_5xx_* in merge group 87ff737 (run 37936701914) and in every group stacked behind it: #1238, #1250, #1245, #1255, #1254, #1231, #1253, #1239, #1259, #1180 and #1242 all failed ci-ok because of this PR.

What I did:

python3 -B -m unittest discover -s scripts/tests passes locally (296 tests, OK, 4 skipped). Final review can re-add this PR once CI is green.


Generated by Claude Code

@mikolalysenko

Copy link
Copy Markdown
Collaborator Author

native (windows-latest, 1.2.23) failed on d6ffc54 (job 113851799121). One cell failed out of 49: 1.2.23 workspace-root vendored FAIL ['refusalCodesExact'], meaning the CLI's warning/refusal codes didn't match the expected set. There was no error text and no transport failure.

I don't think this is caused by this PR:

No fix exists yet. The codes the cell actually saw are in the job's bun-results-windows-latest-1.2.23 artifact (captures/1.2.23-workspace-root-vendored/result.json), which I can't download from this sandbox. I'll re-run the failed job once when the run completes. If it fails again it's real, and I'll dig into it.


Generated by Claude Code

@mikolalysenko

Copy link
Copy Markdown
Collaborator Author

[final reviewer] Tanmay Singla (@Tanmay182003) One non-merge commit landed after your approval on 0913e4e2, so I'm not sending this to the merge queue until you take another look at head d6ffc54:

CI on d6ffc54 is green (ci-ok, clippy), and there are no unresolved threads. Once you re-approve, the next final-review run sends it to the queue.


Generated by Claude Code

Merged via the queue into main with commit 06dab02 Oct 9, 2026
252 of 254 checks passed
@mikolalysenko
Mikola Lysenko (mikolalysenko) deleted the ci-janitor/bun-backtest-http-5xx branch October 9, 2026 15:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci-janitor Opened by the CI janitor routine (flakes, redundant tests, CI perf) Ready for review Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants