fix(worker): use raw.githubusercontent.com as origin; fix deploy probe hostname#504
Merged
fix(worker): use raw.githubusercontent.com as origin; fix deploy probe hostname#504
Conversation
…01 loop Once the CNAME file is in place on gh-pages (Phase 4a-APT), GitHub Pages auto-301s all aaddrick.github.io/claude-desktop-debian/* traffic to pkg.claude-desktop-debian.dev/*. The Worker's origin fetch against aaddrick.github.io gets 301'd by Pages, the 301 passes through to the client, the client follows it back to pkg.<domain>, and the Worker runs again — infinite loop. Observed immediately after merging #503 and Pages finishing the CNAME build: $ curl -I https://pkg.claude-desktop-debian.dev/dists/stable/InRelease HTTP/2 301 location: http://pkg.claude-desktop-debian.dev/dists/stable/InRelease x-github-request-id: 3C94:286425:... x-served-by: cache-yyz4566-YYZ via: 1.1 varnish (Scheme-downgrade to http is a separate Pages quirk when https_enforced=false, which is the case here because DNS points at Cloudflare, not Pages, so Pages can't provision a cert.) raw.githubusercontent.com serves the same gh-pages branch content without Pages' routing layer. All five metadata paths verified to return 200: /dists/stable/InRelease /dists/stable/main/binary-amd64/Packages /KEY.gpg /rpm/x86_64/repodata/repomd.xml /rpm/x86_64/repodata/repomd.xml.asc Also fixes the deploy-worker.yml post-deploy probe which still hardcoded pkg-staging. That's what made #503's deploy show as failed in the Actions UI even though the wrangler deploy itself succeeded — route bound and Worker live, but the probe was resolving a hostname wrangler had just removed. Refs #493, #503 Co-authored-by: Claude <[email protected]>
This was referenced Apr 23, 2026
aaddrick
added a commit
that referenced
this pull request
Apr 23, 2026
The plan doc served its purpose through #494 (merge) → #498 (scaffolding) → #502 / #503 / #504 / #506 / #509 / #510 (cutover). v2.0.5+claude1.3883.0 is the first release through the new pipeline, verified end-to-end on five distros. #493 is closed. Removes docs/worker-apt-plan.md and the two architecture-pointer comments in worker/src/worker.js and worker/wrangler.toml that referenced it. Both files now carry a short self-contained summary of what the Worker does and why. Also corrects worker.js's CDN-hostname reference from objects.githubusercontent.com (the old name) to release-assets (current, matches #509's regex fix). Git history retains the full plan doc for anyone who needs the design rationale; nothing is actually lost.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two follow-ups to #503, both surfaced minutes after merging:
Worker origin fetch loops via Pages auto-301. Once the
CNAMEis live ongh-pages, Pages 301s everyaaddrick.github.io/claude-desktop-debian/*request tohttp://pkg.claude-desktop-debian.dev/*. The Worker'sfetch(ORIGIN + path, request)againstaaddrick.github.ionow receives that 301, passes it to the client, which follows back topkg.<domain>, which runs the Worker again — infinite loop. Observed directly:Fix: switch
ORIGINtohttps://raw.githubusercontent.com/aaddrick/claude-desktop-debian/gh-pages. Same branch content, no Pages routing layer. Verified 200 on all 5 metadata paths (InRelease,Packages,KEY.gpg,repomd.xml,repomd.xml.asc).deploy-worker.ymlpost-deploy probe was still pointed atpkg-stagingafter feat(worker): flip route to production for Phase 4a-APT #503. That's why feat(worker): flip route to production for Phase 4a-APT #503's workflow showed as failed in the Actions UI — wrangler deploy itself succeeded (Worker is live onpkg.claude-desktop-debian.dev), but the probe was resolving a hostname wrangler had just removed.curlreturned exit 6 (couldn't resolve host). Repointed topkg.claude-desktop-debian.dev.Test plan
https://pkg.claude-desktop-debian.dev/dists/stable/InReleasefrom outside — should return 200 with InRelease content (not a 301 loop)gh run rerun 24836419696 --failedfor v2.0.3 — strip step's liveness probe should now succeedRefs #493, #503
Generated with Claude Code
Co-Authored-By: Claude Opus 4.7 [email protected]
95% AI / 5% Human
Claude: diagnosed the origin-fetch 301 loop via response headers (x-github-request-id proves Pages returned the 301), verified raw.githubusercontent.com as a loop-free origin, fixed both the Worker ORIGIN and the stale deploy probe
Human: delegated the Phase 4a-APT execution autonomously; this is a diagnosed follow-up, not scope creep