Vercel Bot Protection can re-challenge a live session mid-visit, and a background fetch can never pass the challenge

CCRTA runs Vercel's Bot Protection managed ruleset in Challenge mode. A rider opened a route page, left it idle for about 21 minutes, and came back to a page that had stopped updating. The error report showed why: every same-origin request from that tab, including SvelteKit's /_app/version.json check, was answered with a 429 and the header x-vercel-mitigated: challenge. The firewall had challenged the session again. The challenge is a JavaScript page that the browser has to load and run, so only a full page load can pass it. A fetch from a polling loop simply receives the 429. The poll code treated it like any other failure and kept backing off, so live updates stopped without any message to the rider.

There were two fixes. In the Vercel firewall, a WAF custom rule now bypasses Bot Protection for the cheap, Redis-cached poll GETs: /api/vehicles, /api/realtime/*, /api/routes/*/schedule and /_app/version.json. Other endpoints, such as /api/translate, and the pages themselves stay protected. In the app, fetchJson checks for a 429 carrying x-vercel-mitigated: challenge and throws a ChallengeError. The poll stops instead of retrying, and a banner in the root layout tells the rider that live updates are paused and offers a reload, which passes the challenge. The first challenge on each page is reported as a warning, to measure how often real riders are re-challenged.

If a site uses Bot Protection challenges and also polls in the background, treat a 429 with x-vercel-mitigated: challenge as its own state. Retrying cannot recover from it; only a page load can.

Receipt: CCRTA Website commit 78bb778 (src/lib/client/challenge.ts, src/lib/client/effect/resilience.ts, src/lib/components/LiveUpdatesPaused.svelte; CLAUDE.md Vercel Firewall section).