Repository navigation
chore(deploy): stage the production worker unbound ahead of the domain cutover - #191
Merged
Merged
Conversation
SPEC confirmed the zone-route binding we planned for the apex does not work — they have tried it before, and it fails from CI just like custom_domain (code 100117 on the externally-managed record; wrangler's clobber flag was removed by Cloudflare). The sanctioned zero-downtime cutover, confirmed with SPEC and ordered so a stray production dispatch is harmless at every step, is instead: 1. Deploy the production env with NO domain binding so the worker exists (polygon-static-production). 2. Immediately land a follow-up PR setting custom_domain = true. Until the swap, any production dispatch fails harmlessly at the domain-registration step (code 100117) — wrangler deploys the script before registering domains, so nothing already deployed or bound is touched. 3. SPEC swaps the existing static.polygon.technology DNS record onto the worker in the Cloudflare dashboard — the actual zero-downtime cutover moment. 4. Dispatch production to verify wrangler now owns the domain (idempotent). This PR is step 1's config: [env.production] drops the route and declares no domain binding. The src/index.ts pass-through worker existed only to guarantee a route could bind an assets-only deployment; with routes abandoned it is dead scaffolding, so the deployment reverts to pure static assets (as staging already validated) and the eslint carve-out for it is removed. wrangler.toml, deploy.yml, and CLAUDE.md document the sequence. The ordering matters: landing custom_domain BEFORE the swap means the only possible premature- dispatch failure is a red run, whereas dispatching with no domain declared AFTER the swap could remove the binding SPEC just created.
MaximusHaximus
force-pushed
the
chore/prod-cutover-spec-swap
branch
from
July 8, 2026 15:34
666bff7 to
55a6fc3
Compare
MaximusHaximus
marked this pull request as ready for review
July 8, 2026 15:36
|
MaximusHaximus
added a commit
that referenced
this pull request
Jul 8, 2026
…m_domain Step 2 of the apex cutover (sequence in #191). The production worker (polygon-static-production, Version a9b0f239) is deployed and unbound; this lands the standard custom_domain binding so the config already matches what SPEC will create when they swap the DNS record onto the worker in the CF dashboard. Ordering rationale: with custom_domain declared before the swap, a premature production dispatch fails harmlessly at domain registration (code 100117) — the script deploys first, and nothing routes to this worker yet. The reverse order (swap first, config later) would leave a window where a deploy with no domain declared could remove the binding SPEC just created. After the swap, deploys idempotently own the domain and production works normally.
MaximusHaximus
changed the title
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
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.
What
Prepares the production environment for the domain cutover:
[env.production]deploys the Worker with no domain binding, so thepolygon-static-productionWorker exists as a deployment target before any hostname is attached to it.Also removes the
src/index.tspass-through Worker script — the deployment is pure static assets (the shape staging already validated), so the script was unnecessary and the ESLint carve-out for it goes too.Why this ordering
A hostname that is already live cannot simply be re-bound by a config push; the binding has to be attached to an existing Worker as a deliberate step. Deploying the Worker unbound first — and landing the
custom_domainconfig as its own follow-up (#192) — makes every intermediate state safe: nothing routes to the new Worker until the domain is attached, and a premature production deploy fails harmlessly rather than affecting live traffic.No changeset — all changes outside
packages/meta/.