After a release changes the shape of a route's data payload, why can a tab loaded from the previous build break on its next navigation?

## What a client-side navigation actually fetches On the first visit the browser receives a document. After that, most meta-frameworks stop asking for documents. The client router intercepts the navigation, fetches the target route's **data** in a serialised form, loads whatever script chunk that route needs, and renders the result in place. Two separate things therefore travel across a deploy boundary: - **the data** — produced by the new release's server-side loading code; - **the code that renders it** — downloaded when the tab first loaded, and therefore from the previous release. They are compiled against each other, but only within a single build. Nothing checks that the payload a new server produced matches the expectations of an old renderer. (The *format* the payload is serialised in is a separate subject; what matters here is that its **shape** — which fields exist and where — is an implicit contract between two releases.) ## Why the old client cannot cope The old renderer reads fields positionally in its own source: it destructures, it indexes, it maps over a list it believes is there. Every one of those reads is an assumption made by a build that no longer exists on the server. | Change in the new release | What the old client does | Severity | |---|---|---| | Field renamed | Reads `undefined` where a value was required | Blank or broken UI, sometimes a thrown render | | Field removed | Same, plus any derived computation collapses | Usually visible and confusing | | Field re-nested one level deeper | Reads an object where it expected a string | Renders an object placeholder or throws | | Type changed (string to object, scalar to list) | Iterates or formats the wrong thing | Often a thrown render | | New field added | Ignores it | Harmless — this is the safe direction | | List entries gain a required discriminator | Falls into a default branch for every entry | Silently wrong, the worst outcome | The last row is the one to remember in an interview. **A crash is a good failure**: an error boundary catches it and the user reloads. Silently rendering wrong values is worse, because nobody notices that the page came from a stale client. ## Making a payload change survivable The rule is the one used for any contract with a consumer you cannot upgrade in lockstep — and inside a skew window, the old tab *is* exactly that consumer, even though you own its code. 1. **Expand, then contract.** Release one adds the new field and keeps writing the old one. Release two, after the skew window has elapsed, removes the old field. Both halves of the window see a payload they can read. 2. **Add, do not move.** Re-nesting or renaming is a remove plus an add executed at the same instant, which is precisely what an old client cannot absorb. 3. **Read tolerantly.** Rendering code that treats unknown values as optional and has a defined behaviour for a missing one degrades instead of exploding. 4. **Carry a shape identifier.** If the payload names the deployment or the payload revision it came from, the client can compare it to its own and choose a full document load when they differ — turning an unpredictable render failure into a deterministic refresh. 5. **Fail forward, not silently.** When rendering does throw, the boundary that catches it should offer a reload rather than a dead end, because a reload genuinely fixes the underlying cause. ## Where the responsibility sits Meta-frameworks differ here. Some version the payload envelope themselves and force a hard navigation when a client asks for data from a build it was not made for; others hand the response straight to old rendering code and leave the consequences to the application. The mechanism to check on any given stack is: **does a data response from another deployment get detected at all, or is it just parsed?** The practical consequences for a team: - Schema changes to a route payload deserve the same review as a public API change *for the duration of the skew window*, not forever. - "We ship the frontend and the backend together, so contracts do not matter" is true across the deploy and false across the window after it. - The blast radius is bounded: the worst case for a read is a broken view that a reload repairs, which is why teams accept a window at all instead of paying for full deployment pinning. - Instrumentation matters more than defensiveness: tag render errors with the client's build identifier, watch whether they cluster in the minutes after a deploy, and only then decide how much compatibility work each release deserves.