Include the browser's release in the rollback rehearsal

Restoring files on a server does not necessarily change every resource a returning browser will use. A service worker may continue serving cached assets. A recovery plan must account for that active client as well as the server deployment.

This fictional handover concerns a product-comparison application with an existing service worker. The successor needs to restore an earlier accepted interface in an isolated rehearsal. No live site is changed.

Identify the versions before changing anything

Release R-1 is the accepted rollback target. Release R-2 changes the comparison interface. The backend remains compatible with both releases in this fixture; a database migration or incompatible API would require a separate recovery decision.

The old deployment process reuses the public path /app.js and a shared asset-cache name. A browser already controlled by the R-2 worker has R-2's script in that cache. Restoring R-1's HTML on the server leaves the returning browser with R-1 markup and R-2 script bytes.

The successor compares the received HTML, controlling worker and script hash with the two release manifests. The mismatch explains the failed comparison controls. It is not evidence that R-1's accepted script has suddenly become defective.

Correct the release arrangement

The team prepares recovery release R-3 containing the accepted R-1 interface with its own identified assets and application cache namespace. Its worker installation prepares that release's resources without overwriting the cache still used by an active R-2 client.

The handover uses the application's supported worker lifecycle. In the isolated fixture, the operator confirms that no unsaved task remains, closes the controlled test clients and allows the prepared worker to activate. A new load then uses the recovery release coherently.

This is not a blanket recommendation to force immediate activation or delete all site storage. MDN's service-worker guidance explains why an older worker and its cache can remain necessary while existing pages use them. The appropriate transition depends on the application's actual lifecycle and data model.

Limit cleanup to the release assets

The recovery procedure identifies the obsolete application-asset caches it may remove. It does not clear unrelated caches, local settings or the application's separate offline data store simply because they share an origin.

The fixture contains a harmless saved preference and an unrelated offline reference item as controls. Their presence is recorded before the procedure. If real pending work existed, its ownership and safe disposition would need to be resolved before closing clients or changing the offline implementation.

Record the completed recovery

After activation and a new load, the received HTML and script hash both match R-3's manifest, which identifies the accepted R-1 interface. The comparison task works with the selected fixture products. A subsequent offline load uses the same release's prepared assets.

The harmless preference and unrelated reference item remain present. A newly opened clean test profile also receives the coherent recovery release. An already-open R-2 client is not declared recovered merely because the server files changed; its transition is accounted for through the supported lifecycle.

The result establishes these fixture clients and resources. It does not prove that every browser in the world has updated, that all user data can be retained through any rollback or that the backend supports arbitrary older versions.

Leave a procedure the successor can repeat

The handover includes the accepted artifact, release manifests, relevant hashes, cache naming rule, worker lifecycle and the task used to verify recovery. It identifies who can approve the operation and which conditions require stopping for another decision.

“Refresh the page” is not enough information when the controlling worker and cached assets determine what the page receives. The successor needs to recognise the actual release and confirm the business task, rather than rely on the server deployment label alone.

Use care and takeover to assess an existing recovery process. The support guide helps define which components and operating responsibilities the ongoing arrangement includes.