index.html is edge-cached for 24h, so deployed fixes can take a day to reach users

Aperta
  • Qualcosa non va?
#686 6 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@bitcoinbrisbane ci sta già lavorando.

Dal 24/9/2026.

  • #687 di @efegokdemir — integrata

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

bug dev-ops

Found while investigating #659, where a fix merged on 22 Sept and a tester still saw the old behaviour a day later.

The policy

$ curl -sI https://app.block52.xyz/
cache-control: public,max-age=10,s-maxage=86400
server: cloudflare
cf-cache-status: HIT

s-maxage=86400 applies to index.html. In a Vite SPA that file is the only unhashed entry point: it names the hashed bundle (/assets/index-BaWNmZ57.js). Cache the HTML for a day and the edge keeps handing out a day-old bundle reference, so a user gets the old JavaScript no matter how recently we deployed.

That is backwards. The hashed assets are content-addressed and safe to cache forever; the HTML that points at them must be revalidated.

Why it matters beyond one stale page

It makes verification unreliable. In #659 the sequence was: fix merged 22 Sept 09:25 UTC → tester reports it still broken 22 Sept 23:57 → the build they were served was replaced at 23 Sept 02:21. Nobody could tell whether the fix was wrong or simply not yet visible, and the same ambiguity will attach to every "still happening" report — including the live-verification pass in #646.

It also means a bad deploy is equally sticky: a rollback does not reach users promptly either.

Suggested

  • index.html: cache-control: no-cache (or max-age=0, must-revalidate). The file is ~1KB; revalidation is cheap and the assets it references still come from cache.
  • /assets/* (hashed): public, max-age=31536000, immutable. Safe precisely because the filename changes with the content.
  • Confirm where the header is set — vercel.json in this repo, or a Cloudflare rule in front of it. The response is served by Cloudflare (cf-cache-status: HIT), so a page/cache rule there can override whatever the origin sends.
  • After changing it, verify: deploy, then curl -sI https://app.block52.xyz/ | grep -iE 'cache-control|last-modified' and check a fresh bundle name appears without waiting.
  • Worth recording the deployed commit somewhere reachable — a <meta name="build-commit"> or a /version.json — so a bug report can say which build it came from. Today the only handle is the bundle filename.

Refs #659, #646.

Lingua principale
TypeScript
Stelle
2
Fork
5
Merge medio
22h 35m
PR unite (30g)
91

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di block52/ui

Tutte le issue di block52/ui

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.