openhands
1a4888df50
Gitea Actions Runner Test / test-job (push) Successful in 3s
CI / check (push) Successful in 32s
CI / tests-integration (push) Successful in 2m11s
CI / tests-unit (push) Successful in 2m16s
CI / tests-ui (push) Successful in 2m54s
CI / preflight (push) Skipped
CI / deploy (push) Successful in 2m47s
The Catalog Studio rendered as a blank white page after a deploy, while the server was serving it correctly: /admin/studio/furni answered 200 with 110KB of HTML and every API it calls answered 200 with data. No script chunk 404ed during the session and no JavaScript threw, so the failure was entirely in what the browser chose to execute. The service worker wrapped /assets/ and /_next/static/ in a Cache Storage entry served cache-first, under a hardcoded name (atom-v3) with no build id and no revalidation. A release therefore could not invalidate it: the browser kept replaying the previous release's chunks against the new HTML, and React never hydrated. The chunk branch also had no .catch(), unlike the API branch below it, so a rejected fetch silently dropped the <script> instead of surfacing a network error the browser could retry. That cache also bought nothing. nginx already sends /_next/static/ and /assets/ as `max-age=31536000, immutable`, and those filenames are content-hashed, so the HTTP cache is both sufficient and safe — a changed file gets a new name. The worker was the only layer able to go stale across a deploy, and it was the one doing it. Both prefixes now fall through to the network and are left to the HTTP cache. The API offline fallback and network-first navigations are unchanged, and the cache names move to v4 so an existing worker is replaced. SW_VERSION moves with them: it is part of the registration URL, so without the bump the browser never refetches sw.js and the old worker keeps running. Unrelated but confirmed while tracing this: /assets/images/themes/arctic-ice.png is requested by the browser and 404s, but that string exists nowhere in the code, the database or the build. It was a stale reference served out of this same cache, not a missing asset.
