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

Abierto
  • ¿Algo no está bien?
#686 6 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@bitcoinbrisbane ya está trabajando en esto.

Desde el 24/9/2026.

  • #687 de @efegokdemir — fusionado

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
2
Forks
5
Merge medio
22 h 35 min
PR fusionados (30 d)
91

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de block52/ui

Todos los issues de block52/ui

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.