How do you handle stale frontend bundles after a breaking API deployment?

Instead of immediately forcing a reload when a request fails, have the backend include its current build version in a response header. The frontend can compare that with the version embedded at build time and show a message such as “A new version is available—refresh to continue.” That avoids silently failing requests and is less disruptive than a hard reload.

The safest default is to keep normal API changes backward-compatible and deploy the backend before the frontend. For genuinely breaking changes, schedule the rollout and track which frontend build versions are still active through telemetry. Once the old build count reaches zero, deploy the breaking change.

Ideally, version the API and introduce something like /v2 when compatibility has to change. In parallel, use hashed or otherwise cache-busted frontend asset filenames so new deployments don't accidentally reuse stale JavaScript files. Most modern build tools handle this automatically.

For a simple application, catching the incompatibility and refreshing the page can work, but it should be a controlled fallback rather than the main deployment strategy. A version check or a friendly refresh prompt gives users a better experience and prevents reload loops.