2 Commits

Author	SHA1	Message	Date
Maurice	bea3af4b45	fix(pwa): recover from a dead chunk and a broken precache after an update (#2524) ... After an update, a tab or a device whose service worker still serves the previous build asks for chunks the update removed. The server answered those requests with index.html and a 200, so the import failed with a MIME error, and everything caching in between was free to keep the HTML as the chunk. A precache install that met a missing file stored it, and Workbox reuses hashed entries by URL, so the device showed "A new version is available" on every load, whatever the reload or the cleared browser cache, and carried the broken entry into every later release that keeps the file's name. The SPA fallback now answers a GET for a build file that is not on disk with a plain 404 (no-store) instead of index.html. A precache install refuses it, so the worker whose cache is complete stays in charge until the new build is. index.html is sent relative to the public dir, which also stops an install living under a dot directory from answering every deep link with a 404. On the client, the reload after a dead chunk (the automatic one and the button on the update screen) no longer goes straight back to the worker that served the broken shell. When that same worker is still in charge and the server answers, its precache and registration are dropped first, so the reload reaches the build the server runs now. Offline, and in offline mode, the shell is kept. Every recovery reload, and the reload of the version handover, asks for the page under a one-off query parameter, so a proxy or CDN that keeps index.html against its headers cannot hand back the stale shell either. A chunk the entry imports statically fails before any of that code runs. shell-guard.js, a small classic script loaded ahead of the entry, watches for exactly that failure and runs the same recovery, once per session. A stylesheet, font or icon that holds a page raises no error at all, so once the app has started and the browser is idle, it looks through the precache for entries that hold a page under a build file's name, fetches each from the server past every cache and puts it back in place. A repaired stylesheet is loaded again, and so are the app's stylesheets when a font was repaired, since the browser does not try a face that failed again in the same document. Only the headers are read, a precache found sound is not looked at again until its entries change, nothing is fetched while nothing is broken, and nothing happens offline, in offline mode or without storage. An answer that is not the file (an auth wall, its login page, a server error) leaves the entry for the next launch. A page the recovery loaded from the network already runs the version the server reports, so the version handover now records it instead of reloading it a second time once the new worker takes over. A page loaded past an older worker that is still in charge, as a hard reload does, still asks for the new worker and records the version only once that has taken over, so the next tab or launch cannot get the old shell without a handover.	2026-09-26 04:22:50 +00:00
Maurice	39b6d9f786	feat(client): catch render errors instead of blanking the page (#1805) ... * feat(client): catch render errors instead of blanking the page There were no error boundaries anywhere, so one throw during render unmounted the whole tree and left the user staring at a white page with no way back. ErrorBoundary holds the state in a class — getDerivedStateFromError has no hook equivalent — and renders a function component for the visible half, so the panel can translate normally. TranslationContext isn't exported, so contextType was not an option anyway. Two things it does beyond showing a message. A chunk that 404s after a deploy gets one reload rather than a retry button: React.lazy caches the rejected promise, so retrying re-throws immediately. And the reload happens once per session, or a genuinely missing chunk would spin the tab. The global handlers in main.tsx cover what no boundary reaches — event handlers and async code. They filter axios errors: the interceptor already redirects on 401/403 and there are 600+ toast.error call sites, so reporting again would mean double toasts and, for the redirects, loops. * feat(client): isolate routes, widgets and the shell chrome The route boundary goes on the single line where all 16 protected routes render their content, inside MobileShell rather than around it: the navigation survives, so a broken page is something the user can walk away from instead of a dead end. The mobile --m-* tokens live on the shell's .m-root too, so a fallback outside it would render invisible. key={location.pathname}, not resetKeys — ProtectedRoute is the same component at the same position for every protected route, so otherwise a failure could follow the user across a navigation. The public routes render outside ProtectedRoute and were therefore uncovered, including /login (where people land when everything else failed) and the two anonymous share pages. PublicRoute wraps those seven. The five global widgets and the shell chrome get fallback={null} each: a broken widget should disappear quietly, and if BottomNav dies the user loses the very thing they need to leave the route. * feat(client): isolate the GL maps and the plugin frame Both map wrappers put the boundary outside their Suspense, not inside: Suspense handles a pending promise, a rejected one throws straight past it. Falling back to the Leaflet renderer keeps a usable map rather than showing an error card — the same downgrade the Suspense fallback already does while loading. PluginFrame is third-party code rendering in our tree; a throw there should cost the plugin, not the page. resetKeys={[pluginId]} so switching plugins clears it. The locale loader had no .catch (TranslationContext.tsx). After a deploy the chunk can be gone, which produced an unhandled rejection and left the UI silently on the previous language. It now keeps the strings it has and says so in the console.	2026-08-06 23:42:57 +02:00