A PWA deploy does not replace every open tab at once. One user may have new HTML controlled by an old worker while another has an old page that just downloaded a new worker waiting to activate.
The project keeps an application version and a service-worker build version visible to registration logic. Update handling can then compare versions, wait for controller change, and request a reload at a controlled point.
What was actually going wrong
Changing cache contents without coordinating page and worker versions left mixed generations running together.
What I tried
- Telling users to hard-refresh after every deploy
- Renaming caches without reporting the active build
- Calling registration repeatedly from several scripts
Version constants, one registration path, worker messaging, and controller-change handling establish which generation owns the page.
Why it worked
The application can identify drift instead of guessing from symptoms.
A service worker is a second deployed runtime and needs an explicit release handshake.
Where EACI uses this today
The Main PWA checks worker support and coordinates updates through the central registration module.
This journal covers real engineering on EACI Companion / The Veil. Companions include Caelum, Chad, Natalia, Atreus, Luna, Roxy, and Cael. Journal articles stay family-safe in content. See Privacy and Ethics.