fix(deploy): scope npm run deploy to --env production#175
fix(deploy): scope npm run deploy to --env production#175chitcommit wants to merge 1 commit intomainfrom
Conversation
Workers Builds CI runs npm run deploy verbatim. With "deploy": "wrangler deploy" (no --env), wrangler targets the top-level config block. Top-level only declares secrets_store_secrets — every other binding (KV, DO, D1, R2, Vectorize, queues, services, AI, Worker Loader, vars) is correctly scoped under env.production but never read by the CI deploy. Result: every CI deploy ships a worker with 16 secrets and zero other bindings. The runtime tries to use env.MCP_AGENT, env.DB, env.OAUTH_KV, etc, gets undefined, and Cloudflare returns 1101 across every path because the fetch handler chain resolves to non-Response. Local "wrangler deploy --env production" sees the env block and produces a healthy bundle (this is how 3d46be98 was deployed). Same wrangler.jsonc, different invocation, opposite outcomes. Fix: scope the default deploy script to --env production. Add explicit deploy:staging and deploy:production aliases for clarity. The existing wrangler.jsonc already declares everything per-env (lines 16-20 even warn that env blocks must be explicit) — no config change needed. Verifying after merge: wrangler versions view <new_id> --env production should show ~50 binding lines (full set) instead of just the 17 secrets_store_secrets entries. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
chittyconnect | c295666 | May 01 2026, 01:02 PM |
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 21 minutes and 31 seconds.Comment |
There was a problem hiding this comment.
Pull request overview
Scopes the default npm deploy command to Cloudflare’s production environment to prevent CI/Workers Builds deployments from unintentionally using the top-level Wrangler config (missing most bindings) and causing production outages.
Changes:
- Change
npm run deployto runwrangler deploy --env production. - Add explicit
deploy:staginganddeploy:productionscript aliases for clarity.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "deploy": "wrangler deploy --env production", | ||
| "deploy:staging": "wrangler deploy --env staging", | ||
| "deploy:production": "wrangler deploy --env production", |
This PR's merge will trigger Workers Builds → production deploy. Verify the diff and manually merge when ready. The current production worker (
3d46be98, healthy) is a manual rollback; the moment any commit lands on main, CI re-deploys.Summary
package.jsonhad"deploy": "wrangler deploy"with no--envflag. Workers Builds runs that verbatim. Without--env, wrangler reads only the top-level config block, where the only declared binding issecrets_store_secrets. Every other binding (KV / DO / D1 / R2 / Vectorize / queues / services / AI / Worker Loader / vars / routes / triggers) is correctly scoped underenv.productionper the canonical pattern documented inwrangler.jsonc:16-20.Net effect: every CI deploy produces a worker with 17 secrets and zero resource bindings. The runtime tries to use
env.MCP_AGENT/env.DB/env.OAUTH_KV/ etc, getsundefined, and the OAuthProvider chain resolves to non-Response— Cloudflare returns 1101 across every path.This was the regression mechanism for both:
c3cd2a6d(post-PR-fix: MCP portal zero-trust fixes #168 deploy, took down prod for ~12h)a48c8f18(post-PR-fix: reconcile uncommitted production hotfix to main #174 deploy from earlier today, also took down prod, rolled back to3d46be98viawrangler rollback)Local
wrangler deploy --env productionreads the env block and produces a healthy bundle — same wrangler.jsonc, different invocation, opposite outcomes. The fix is one line of script change; nowrangler.jsoncedits needed.Diff
The aliases are belt-and-suspenders:
npm run deployalways means production now, but explicitdeploy:staging/deploy:productionaliases let callers be unambiguous. Revertable in one line if Workers Builds is later configured to use a different command.Verification plan (post-merge)
If the new deploy is broken,
wrangler rollback 3d46be98-344c-4711-9e44-f5418ca84881 --env productionrestores the known-good state.Why open this with auto-merge disabled
I broke prod once today by letting a merge trigger an auto-deploy from a CI invocation that was structurally wrong. Same root cause that broke prod yesterday after PR #168. Treating this PR as a controlled deploy gate so we observe the next CI build before allowing it to ship.
🤖 Generated with Claude Code