Skip to content

fix(release): CF_API_BASE typo — deploy lane 403'd since creation - #208

Merged
nish3451 merged 1 commit into
mainfrom
fix/cf-api-base-typo
Aug 20, 2026
Merged

fix(release): CF_API_BASE typo — deploy lane 403'd since creation#208
nish3451 merged 1 commit into
mainfrom
fix/cf-api-base-typo

Conversation

@nish3451

@nish3451 nish3451 commented Aug 20, 2026

Copy link
Copy Markdown
Collaborator

One-line root cause of the dead deploy lane: CF_API_BASE was https://api.cloudflare.com/api/v4; the real base is client/v4. Every API call 403'd, so the lane failed closed on every run and the site stayed stale from 2026-06-20 until manual deploys on 2026-08-20. Proven by an in-runner probe: same token, same env — literal client/v4 URL returns 200, the script 403s.

Regression guard: test-pages-release.mjs now pins the literal base string — its mocks previously derived expected URLs from the constant itself, so 38 checks stayed green around a broken URL.

node scripts/test-pages-release.mjs: 38 checks, 0 failures. Secrets are already provisioned (CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID); after merge the deploy lane should go green on its own.

Greptile Summary

The PR corrects the Cloudflare API base used by the public-site release lane and adds a literal regression check so URL mocks cannot conceal the same typo again.

  • Changes CF_API_BASE from the invalid /api/v4 path to /client/v4.
  • Adds an unconditional test assertion for the canonical API base.
  • The existing release tests exercise both Cloudflare request paths and run in CI and the pre-deploy gate.

Confidence Score: 5/5

The PR appears safe to merge, with the corrected API base consistently used by the existing Cloudflare request paths and protected by the release test gate.

The production constant now forms the expected /client/v4/accounts/... URLs, and the new literal check prevents the URL mocks from passing if that base regresses.

Important Files Changed

Filename Overview
scripts/publish-public-site.mjs Corrects the shared Cloudflare API base consumed by project lookup and deployment rollback requests; no actionable issue found.
scripts/test-pages-release.mjs Adds a literal assertion that closes the prior self-referential mock gap; no actionable issue found.

Reviews (1): Last reviewed commit: "fix(release): CF_API_BASE typo /api/v4 -..." | Re-trigger Greptile

… on every call since creation

The publish pipeline's Cloudflare API base was /api/v4 instead of the
documented /client/v4, so captureProductionIdentity 403'd on every run and
the lane refused to deploy — the site sat stale 2026-06-20..2026-08-20.
The mocks in test-pages-release.mjs derive their expected URLs from the
constant itself, which is why 38 green checks never caught it; the test now
pins the literal base string so a mock can never hide it again.
@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@coderabbitai

coderabbitai Bot commented Aug 20, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@nish3451, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 47 minutes

Limit details: You’ve used the included review currently available.

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Free

Run ID: 6b307a5f-6c57-4d93-a2ba-558fdd5bc483

📥 Commits

Reviewing files that changed from the base of the PR and between e18c176 and 6ca3790.

📒 Files selected for processing (2)
  • scripts/publish-public-site.mjs
  • scripts/test-pages-release.mjs

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login.

Comment @coderabbitai help to get the list of available commands.

@nish3451
nish3451 merged commit b64f242 into main Aug 20, 2026
5 checks passed
@nish3451
nish3451 deleted the fix/cf-api-base-typo branch August 20, 2026 15:37
nish3451 pushed a commit that referenced this pull request Aug 20, 2026
…rally, correct workflow headers that told readers to expect red

- publish: a blip on the Cloudflare project read during promotion polling is
  retried; only an identity still unreadable on the last attempt fails the
  release. Without this a transient 500 would fail a release that did go live.
- test-deploy-public-site-workflow: assert the pipeline proves promotion AFTER
  the upload and BEFORE the acceptance, so a refactor cannot silently drop it
  (2 of these checks fail against the pre-change script).
- live-site-check.yml said the nightly staleness alarm "is expected to FAIL".
  That is how a red alarm becomes wallpaper. Red now means act; the site was
  restored 2026-08-20.
- deploy-public-site.yml claimed the Pages token was unprovisioned and the lane
  would stay red until it landed. It has been provisioned since 2026-08-20
  under the secret name CLOUDFLARE. Header now records the real failure history
  (#208 /client/v4, #209 Node 22, #211 dead acceptance) and the promotion proof.
- Lane evidence report.
nish3451 added a commit that referenced this pull request Aug 22, 2026
…ll 12 URLs (#223)

Live https://tinystudio.in/llms.txt is byte-identical to origin/main
(MD5 c6d3893d…), all five per-app support/privacy trust pages return
HTTP 200, and the release-lane live checker passes 240/240 — the
deploy-path repairs (#208/#209/#211) cleared the stale June-20 bundle.

Co-authored-by: minimax-vps <minimax-vps@MiniMax.local>
Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
nish3451 added a commit that referenced this pull request Aug 22, 2026
…-08-20) (#210)

The soft-404 defect (unknown URL returns HTTP 200 with the homepage body)
is now fixed on https://tinystudio.in: a random nonce URL returns HTTP 404
with the real 'Page not found' page (title 'Page not found • Tiny Studio',
H1 'This page could not be found.', noindex meta, shared header/footer
chrome, no canonical to '/'). The dedicated live soft-404 checker passes
18/18 and the static unit test passes 21/21.

Previous 2026-08-17 reverify (PR #189) concluded the soft-404 was real and
live, blocked on the missing CLOUDFLARE_API_TOKEN. The deploy lane has
since been repaired end-to-end:
- PR #198: workflow reads secrets.CLOUDFLARE_API_TOKEN || secrets.CLOUDFLARE
- PR #199: PAGES_PROJECT = 'tiny-studio' (was the broken 'tiny-studio-3f5'
  subdomain), wrangler --project-name fixed
- PR #208: CF_API_BASE /api/v4 -> /client/v4 (captureProductionIdentity
  was 403'ing on every call since the lane was created)

With the lane able to capture a real canonical_deployment, the daily
schedule + the next main push published the filtered public/ bundle, and
the live 404 page now appears. Live evidence (curl, live checker, deploy
acceptance section C, deploy-bundle gate) all agree; item is closed on
the live proof, not a code task.

Report only; no source file changed. Files:
  + .lane/reports/docs-lane1-soft-404-reverify-20260820.md

Co-authored-by: minimax-vps <minimax-vps@MiniMax.local>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant