fix(network): a download that falls back to git.magicbean.dev stays there, not redirected to the git-cdn that just failed #122

Merged

HumanBean merged 1 commit from HumanBean/LongshotLauncher:fix/cdn-fallback-direct into main

2026-11-15 22:57:17 +00:00

HumanBean commented

2026-11-15 22:55:46 +00:00

Owner

Refs #120. This does not fix that issue's first report, where the TLS handshake to git.magicbean.dev itself fails too: nothing in the launcher's fall back can help there.

What changes

git.magicbean.dev redirects release files (/<owner>/<repo>/releases/download/...) and packages (/api/packages/...) to git-cdn (the zone's redirect rule). The rule leaves a link with cdn=0 in its query alone, and Forgejo then serves the file itself (from its storage, another host than git-cdn).
CdnFetcher.Direct adds cdn=0 to such a link, once. Every download asked of git.magicbean.dev carries it: the fall back after the CDN failed, a tool's own git.magicbean.dev link (Expand), and all of them with LONGSHOT_LAUNCHER_NO_CDN=1, which was redirected to the CDN as well and so never left it for a download.
Release lists and the rest of the API are unchanged: they are not redirected.

Checked

python -I tests/test_launcher_core.py (1346 checks) and python -I tests/test_release.py (31 tests) pass. CdnChecks now expects the cdn=0 link wherever git.magicbean.dev is asked, and checks Direct itself.
By hand with curl: https://git.magicbean.dev/MagicBeanDev/Longshot/releases/download/v3.0.0-rc.4/SHA256SUMS answers 302 to git-cdn; with ?cdn=0 it gives the same 290 bytes as the CDN without going there. The llvm-mingw package link behaves the same.
Not run in the launcher on a PC where git-cdn fails: none at hand.

Nothing on screen changes.

🤖 Generated with Claude Code

When git-cdn.magicbean.dev cannot be reached, the launcher's fall back to git.magicbean.dev is redirected straight back to git-cdn, so a PC that fails on the CDN alone cannot download a release's `SHA256SUMS`, a builder or a tool at all (the second report in #120: the API on git.magicbean.dev answers 200, the Build button stays off). Refs #120. This does not fix that issue's first report, where the TLS handshake to git.magicbean.dev itself fails too: nothing in the launcher's fall back can help there. ## What changes - git.magicbean.dev redirects release files (`/<owner>/<repo>/releases/download/...`) and packages (`/api/packages/...`) to git-cdn (the zone's redirect rule). The rule leaves a link with `cdn=0` in its query alone, and Forgejo then serves the file itself (from its storage, another host than git-cdn). - `CdnFetcher.Direct` adds `cdn=0` to such a link, once. Every download asked of git.magicbean.dev carries it: the fall back after the CDN failed, a tool's own git.magicbean.dev link (`Expand`), and all of them with `LONGSHOT_LAUNCHER_NO_CDN=1`, which was redirected to the CDN as well and so never left it for a download. - Release lists and the rest of the API are unchanged: they are not redirected. ## Checked - `python -I tests/test_launcher_core.py` (1346 checks) and `python -I tests/test_release.py` (31 tests) pass. `CdnChecks` now expects the `cdn=0` link wherever git.magicbean.dev is asked, and checks `Direct` itself. - By hand with curl: `https://git.magicbean.dev/MagicBeanDev/Longshot/releases/download/v3.0.0-rc.4/SHA256SUMS` answers 302 to git-cdn; with `?cdn=0` it gives the same 290 bytes as the CDN without going there. The llvm-mingw package link behaves the same. - Not run in the launcher on a PC where git-cdn fails: none at hand. Nothing on screen changes. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

HumanBean added 1 commit

2026-11-15 22:55:46 +00:00

fix(network): a download that falls back to git.magicbean.dev stays there, not redirected to the git-cdn that just failed (#120 )

CI / Compile and test (pull_request) Has been skipped

Details

CI / Conventional Commit title (pull_request) Successful in 4s

Details

f8f376d0a1

git.magicbean.dev redirects release files and packages to git-cdn.magicbean.dev, so the fall back after the CDN failed (and
LONGSHOT_LAUNCHER_NO_CDN=1) went to the same host again: a PC that cannot reach git-cdn alone could not download at all. Such
downloads now carry cdn=0, which the redirect rule leaves alone.

Co-Authored-By: Claude Fable 5.2 <[email protected]>