[ntucker]

Requested by Nathaniel · project thread

Follow-up to #4415.

Motivation

Vercel answers every miss with the deployment root's one 404.html. So a bookmark, search result or external link to a missing page:

• under /next/ shows the root (0.18) site's 404 app, labelled with the root's version;
• under a locale (/es/...) shows the English 404;
• on an archive host (<v>.dataclient.io) gets the root's 404.html, whose /assets/... the host rewrite maps to archives/<v>/assets/..., which don't exist: no CSS or JS.

vercel build's output confirms it: the error phase has a single route, { "src": "^(?!/api).*$", "dest": "/404", "status": 404 }.

Solution

docs deploy already edits .vercel/output/config.json (to move the archive host rewrite). It now also lists every 404.html in the deployed build (find website/build -mindepth 2 -name 404.html) and adds one error-phase route per build ahead of the root's catch-all, so it adapts to whatever was built (English-only previews, /next/ or not, archives with or without locales):

{ "src": "^(?:/archives/0\\.17)?/es/", "has": [{ "type": "host", "value": "0\\.17\\.dataclient\\.io" }], "dest": "/archives/0.17/es/404", "status": 404 },
{ "src": "^(?:/archives/0\\.17)?/(?!api)", "has": [{ "type": "host", "value": "0\\.17\\.dataclient\\.io" }], "dest": "/archives/0.17/404", "status": 404 },
{ "src": "^/next/es/", "dest": "/next/es/404", "status": 404 },
{ "src": "^/next/", "dest": "/next/404", "status": 404 },
{ "src": "^/es/", "dest": "/es/404", "status": 404 },
{ "src": "^(?!/api).*$", "dest": "/404", "status": 404 }

Archive routes go first (their hosts' paths look like the root's), then the longest prefix wins. Archive src accepts both the host's own path and the rewritten /archives/<v>/... one, since the miss may reach the error phase after the host rewrite. The step fails if the config has no error phase.

Checked by running vercel build (CLI 63.1.2, the pinned version) on a mock build with /es, /next, /next/es and an archive, then the new step: routes above; with an English-only build only the root route remains. Not checked on a live deploy: previews have no /next/ or archives, and dataclient.io isn't reachable from my environment, so the first production deploy is where /next/<missing> and /es/<missing> show it.

Docs: .cursor/rules/ci-config.mdc (and generated .claude/rules), website/scripts/snapshot/README.md.

---

Generated by Claude Code

---

Note

Medium Risk
Changes production Vercel routing for all 404 responses across root, locales, /next/, and archive hosts; mis-generated routes could break error pages until the next deploy.

Overview
Fixes broken or wrong-version 404 pages when Vercel falls through to the deployment root’s single 404.html (e.g. unstyled archive hosts, /next/ showing the current site’s 404, locales showing English).

The docs deploy job in site-preview.yml now patches .vercel/output/config.json after vercel build: it discovers every built 404.html (root, locales, /next/, archives) and inserts error-phase routes ahead of the root catch-all—archive hosts first with has: host, then longest path prefix—so each slice serves its own styled 404. The step errors if the config has no error phase.

CI/agent docs (ci-config.mdc / generated .claude/rules) and website/scripts/snapshot/README.md document this alongside the existing archive rewrite reordering.

^{Reviewed by Cursor Bugbot for commit 2ca231c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 2ca231c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-21T03:39:11.293419Z	2ca231c	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[ntucker]

Staff engineer (Cursor agent): LGTM. One idea for after this lands; nothing needs to change in this PR.

What I checked: I ran the new jq block from 596fe8b on a mock website/build that has 404.html at the root, next/, next/es/, es/, archives/0.17/ and archives/0.17/es/, plus a config with a single error-phase catch-all. The routes came out exactly as the PR body shows: archive host routes first (the locale one ahead of the bare one), then /next/es/, /next/, /es/, and the root catch-all last. Because of -mindepth 2, the root's own 404.html doesn't get a duplicate route. What I only read: that the error phase in Vercel's real output has just that one route, and how the routes behave on a live deploy. I didn't run vercel build and couldn't test a live deploy.

Direction: Changing vercel build's output after the fact is the right call here. vercel.json can't put routes in the error phase next to rewrites, and I don't know of a Docusaurus or Vercel setting that serves a separate 404 page per prefix. Discovering the routes from the files that were actually built, instead of from a list of versions and locales, is what keeps this from drifting.

FOLLOW_UP (after merge, only if it comes up again): docs deploy now makes two hand-written jq edits to .vercel/output/config.json, moving the archive rewrite and adding these 404 routes. Both only run during a real deploy, so a mistake in either one first shows up on master. If a third edit comes along, or one of these needs changing, I'd move them into one small script under website/scripts/ and test it against a fixture config like the mock above, which is the check you already ran by hand. Until then, two inline blocks that each fail loudly are cheaper than adding a script.

[github-actions]

Docs preview: https://docs-site-pr-4442-data-client.vercel.app

Built from 2ca231c merged into master (this build). English only: this PR doesn't touch translations.