public/sw.js defines:
const STATIC_ASSETS = ['/', '/about', '/streams', '/create', '/dashboard'];
...
const isStaticPage = STATIC_ASSETS.some((page) => url.includes(page));
Because '/' is one of the STATIC_ASSETS entries and the check is a plain substring .includes() (not an exact match or path-prefix check), isStaticPage evaluates to true for every same-origin URL — every URL path contains the character /. This means the intended "only cache-and-serve these 5 shell routes" logic (lines 52-77) actually applies to every same-origin GET request that isn't caught by the asset-extension regex first, not just the 5 intended pages. In a real deployment where the app starts making same-origin API/RPC-proxy requests, this service worker would attempt to cache-match and serve stale cached responses for requests that were never meant to be cached.
Fix: use an exact-match check (e.g. STATIC_ASSETS.includes(new URL(url).pathname)) instead of substring matching, and don't rely on '/' alone as a stand-in for "is a static shell route."
public/sw.jsdefines:Because
'/'is one of theSTATIC_ASSETSentries and the check is a plain substring.includes()(not an exact match or path-prefix check),isStaticPageevaluates totruefor every same-origin URL — every URL path contains the character/. This means the intended "only cache-and-serve these 5 shell routes" logic (lines 52-77) actually applies to every same-origin GET request that isn't caught by the asset-extension regex first, not just the 5 intended pages. In a real deployment where the app starts making same-origin API/RPC-proxy requests, this service worker would attempt to cache-match and serve stale cached responses for requests that were never meant to be cached.Fix: use an exact-match check (e.g.
STATIC_ASSETS.includes(new URL(url).pathname)) instead of substring matching, and don't rely on'/'alone as a stand-in for "is a static shell route."