Offer a safe reload when an open page needs a new application version #33

Open
opened 2026-11-01 20:11:50 +00:00 by viacheslavshuka · 0 comments

Outcome

An open browser can retain old JavaScript after deployment. Provide a controlled recovery path when the page requires the new version, including an obsolete lazy-loaded asset.

Acceptance criteria

  • A page that requires a new application version shows a clear update notice and Reload action.
  • Failed loading of an obsolete application chunk offers the same recoverable path instead of leaving an unexplained blank screen.
  • The page never automatically reloads a form with unsaved edits. The user chooses when to proceed after a warning about memory-only input loss.
  • Reload does not replay pending or uncertain submissions. A booking or approval still requires an explicit new action and current server checks.
  • The browser distinguishes an update requirement from an ordinary temporary connection failure when evidence permits. It does not trap users in an automatic reload loop.
  • A successful chosen reload obtains current HTML and can load the current application assets under the deployment caching policy.
  • The notice and recovery action remain usable by keyboard and on small screens. Internal chunk URLs and stack traces are not the user-facing explanation.

Validation design

Load an old production build, deploy a new asset set, and request an old lazy chunk. Assert an actionable notice with preserved unsaved input and no write replay. Test a transient network failure separately to detect false update loops. After explicit reload, verify current build identity and a usable route.

Dependencies

## Outcome An open browser can retain old JavaScript after deployment. Provide a controlled recovery path when the page requires the new version, including an obsolete lazy-loaded asset. ## Acceptance criteria - A page that requires a new application version shows a clear update notice and Reload action. - Failed loading of an obsolete application chunk offers the same recoverable path instead of leaving an unexplained blank screen. - The page never automatically reloads a form with unsaved edits. The user chooses when to proceed after a warning about memory-only input loss. - Reload does not replay pending or uncertain submissions. A booking or approval still requires an explicit new action and current server checks. - The browser distinguishes an update requirement from an ordinary temporary connection failure when evidence permits. It does not trap users in an automatic reload loop. - A successful chosen reload obtains current HTML and can load the current application assets under the deployment caching policy. - The notice and recovery action remain usable by keyboard and on small screens. Internal chunk URLs and stack traces are not the user-facing explanation. ## Validation design Load an old production build, deploy a new asset set, and request an old lazy chunk. Assert an actionable notice with preserved unsaved input and no write replay. Test a transient network failure separately to detect false update loops. After explicit reload, verify current build identity and a usable route. ## Dependencies - [#26: Package and serve the website and API from one image](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/26). Supplies production asset delivery and HTML revalidation. - [#32: Use one application version across builds and release artifacts](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/32). Supplies application version identity. ## Related work - [#25: Preserve unsaved form input during reauthentication](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/25) - [#24: Keep browser data useful during slow or lost connections](https://code.viacheslavshuka.com/viacheslavshuka/quorum/issues/24)
Sign in to join this conversation.
No description provided.