Version
v1.22.0 (Docker, ghcr.io/autobrr/qui). v1.23.0 changelog shows no PWA/service-worker change.
Describe the bug
A normal reload (Cmd+R / F5) of any client route — e.g. /instances/1 — fails with net::ERR_FAILED ("This site can't be reached"). A hard reload (Cmd+Shift+R) loads the page fine. Because a hard reload only bypasses the service worker for that single load, the failure returns on the next normal reload.
It points at the service-worker navigation handler. /sw.js registers NavigationRoute(createHandlerBoundToURL("index.html")) (denylist /api) with skipWaiting + clientsClaim, so every navigation is served the precached index.html from Cache Storage instead of the network. Hard reload is the one path that skips the SW, and it's the one that works — the backend is healthy (GET / and /assets/* return 200 directly from the server, through an nginx reverse proxy that does no caching). So the navigation is failing inside the SW's cached-shell handler rather than falling back to the network.
Possibly relevant: index.html (the precache source) and /sw.js are both served with no Cache-Control header (no ETag/Last-Modified either).
To Reproduce
- Load qui, log in, open an instance (
/instances/1) so the SW is installed and controlling.
- Use it for a while / across a version update.
- Cmd+R (or F5) →
net::ERR_FAILED.
- Cmd+Shift+R → loads fine.
- Cmd+R again → fails again.
Expected behavior
A normal reload loads the page. On a precache miss the navigation handler should fall back to the network instead of returning ERR_FAILED.
Workaround
DevTools → Application → Service Workers → Unregister, then Clear site data. Incognito (no SW) never hits it.
Environment
- qui v1.22.0, Docker, served at the root of a dedicated hostname (no base URL / subpath) behind an nginx reverse proxy with no response caching.
- Chromium-based browser on macOS.
Suggested fix
- Make the navigation fallback network-tolerant: serve precached
index.html, but fall back to the network on a precache miss instead of erroring.
- Serve
sw.js and index.html with Cache-Control: no-cache.
Version
v1.22.0 (Docker,
ghcr.io/autobrr/qui). v1.23.0 changelog shows no PWA/service-worker change.Describe the bug
A normal reload (Cmd+R / F5) of any client route — e.g.
/instances/1— fails withnet::ERR_FAILED("This site can't be reached"). A hard reload (Cmd+Shift+R) loads the page fine. Because a hard reload only bypasses the service worker for that single load, the failure returns on the next normal reload.It points at the service-worker navigation handler.
/sw.jsregistersNavigationRoute(createHandlerBoundToURL("index.html"))(denylist/api) withskipWaiting+clientsClaim, so every navigation is served the precachedindex.htmlfrom Cache Storage instead of the network. Hard reload is the one path that skips the SW, and it's the one that works — the backend is healthy (GET /and/assets/*return 200 directly from the server, through an nginx reverse proxy that does no caching). So the navigation is failing inside the SW's cached-shell handler rather than falling back to the network.Possibly relevant:
index.html(the precache source) and/sw.jsare both served with noCache-Controlheader (no ETag/Last-Modified either).To Reproduce
/instances/1) so the SW is installed and controlling.net::ERR_FAILED.Expected behavior
A normal reload loads the page. On a precache miss the navigation handler should fall back to the network instead of returning
ERR_FAILED.Workaround
DevTools → Application → Service Workers → Unregister, then Clear site data. Incognito (no SW) never hits it.
Environment
Suggested fix
index.html, but fall back to the network on a precache miss instead of erroring.sw.jsandindex.htmlwithCache-Control: no-cache.