fix(public): guard the live site against soft-404s and flag the stale deployment - #62
fix(public): guard the live site against soft-404s and flag the stale deployment#62nish3451 wants to merge 1 commit into
Conversation
The repo ships public/404.html, but tinystudio.in still serves the homepage with HTTP 200 for every unknown URL. The deployed bundle is stale: the live homepage matches commit 07acd07 (#4), predating the 404 page added in #34, and no in-repo guard could catch that - the static test only reads files. Add scripts/check-public-live-soft-404.mjs, which hits the deployed site with a random unknown URL and requires a real 404 with the not-found page (never the homepage). Wire it into npm test/ci (with a SKIP_LIVE_CHECKS=1 escape hatch) and add a nightly live-site-check workflow, so a stale or misconfigured deployment fails loudly within a day instead of rotting silently.
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 28 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Comment |
|
Superseded by #84: this PR wires the live-site soft-404 check into the blocking npm-run-ci chain, so repo-checks stays red on every PR while the deployment is stale (the 5 live-site FAILs in this PR's own CI log). #84 lands the same detector with the corrected wiring: npm run ci and npm test stay green on repo state alone, and the check runs from npm run site:check-live, the nightly live-site-check.yml workflow, and the deploy lane's post-publish verification. Recommend closing this PR. |
…in (#84) PR #62 wired check-public-live-soft-404.mjs into npm run ci, so every pull request stayed red while the deployment is stale (the live site still serves the June-20 bundle: unknown URLs return 200 with the homepage). The blocking chain must stay green on repo state alone. Land the detector without the blocking wiring: - scripts/check-public-live-soft-404.mjs (from #62, header corrected) - npm run site:check-live entry point - .github/workflows/live-site-check.yml: nightly + manual dispatch, the within-a-day loud signal for a stale or misconfigured deploy (deploy lane already verifies the live site after each publish). npm run ci and npm test are untouched: the chain passes with the live site stale, and the detector fails loudly on demand instead.
|
Closing as a zombie PR — superseded by #84 (merged 2026-08-11, d898707). #84 landed this PR's detector |
1 participant
Problem
Every unknown URL on tinystudio.in returns HTTP 200 with the full homepage (soft-404). Verified live:
Even
https://tinystudio.in/404.htmlserves the homepage.Root cause
The repo already fixed this in #34 (
public/404.html+ static tests), but the deployed site is stale: the live homepage is byte-identical to commit07acd07(#4, June 20) — full-file diff is only Cloudflare's edge email-obfuscation transforms. Every public fix merged since (#26 JSON-LD, #29 disambiguation, #34 404 page, #35 footer, …) has never been deployed.The blind spot:
test-public-soft-404.mjsonly reads repo files, so it passes while production is broken. Nothing detected the stale deploy.This change (the detector)
scripts/check-public-live-soft-404.mjs— hits the deployed site with a random unknown URL and requires a real 404 with the not-found page, never the homepage; also asserts/404.htmlserves the 404 page and a real page still works.npm test/npm run ci(escape hatch:SKIP_LIVE_CHECKS=1)..github/workflows/live-site-check.yml— nightly + manual-dispatch run on the vps-verify runner, so a stale/misconfigured deploy fails loudly within a day.Current live result (proof the detector works)
CI on this PR will be red by design until the site is re-deployed from
origin/main— that is the loud signal this packet's item asked for.Required follow-up (outside repo code)
Re-deploy the public site from
origin/main(deploy mechanism is external to this repo — no CI deploy job or wrangler config exists here). Then this check and the nightly workflow go green, and unknown URLs return real 404s.