Clarify RSC deployment skew and compatibility-aware recovery scope

Problem

Frameworks built on @vitejs/plugin-rsc need to handle RSC deployment skew.

A common failure mode is:

1. A user has an old browser tab open.
2. A new deployment goes live.
3. The old tab sends an RSC navigation, route-discovery request, or server action to the new server.
4. The old client may no longer be able to decode or safely use the new server response.

Frameworks can own the recovery behavior themselves. For example, React Router can return a 204 reload response and reload the document on the client instead of trying to decode an incompatible RSC payload.

The open question is what compatibility signal frameworks should compare.

Coarse Skew Recovery vs Compatibility-Aware Recovery

There seem to be two different levels of recovery.

1. Coarse skew recovery

This answers:

Is this browser tab from a different deployment?

If a deployment makes Vite base deployment-specific, then base can already be used for this.

For example:

base: "/assets/deploy-abc123/"

That is useful for “reload old tabs after a new deploy” behavior.

2. Compatibility-aware recovery

This answers a more specific RSC question:

Is this old client actually incompatible with the new server?

This is different from deployment identity. A new deployment does not necessarily mean the old client must reload. With RSC, it seems possible to support “no reload required” deployments when the relevant client/server contract has not changed.

That compatibility signal seems like it may need to account for RSC/build state such as:

• client reference keys and rendered exports
• server reference keys and exported functions
• final assets manifest
• final client/RSC/SSR output relevant to the RSC payload contract
• server action encryption identity, when action closure encryption is emitted
• relevant RSC runtime package versions or singleton dependencies

This would let a framework distinguish:

• “new deploy, but the old client can continue safely”
• “new deploy, incompatible RSC contract, reload the document”

Question

Should @vitejs/plugin-rsc support compatibility-aware recovery as a first-class concept?

If yes, what surface should frameworks use?

Possible directions:

1. Frameworks use deployment-specific base for coarse skew recovery only.
2. Frameworks derive a compatibility version from the existing experimental manager.
3. @vitejs/plugin-rsc exposes or documents a stable compatibility primitive, such as a finalized compatibility version or manifest.

The intent is not for @vitejs/plugin-rsc to own framework-specific recovery behavior. React Router can own the request protocol and document reload behavior.

The question is whether plugin-rsc should own or document the lower-level RSC compatibility signal, since it has the most authoritative view of the RSC graph and build output.

Related Context

• React Router RSC skew issue: https://github.com/remix-run/react-router/issues/14849
• React Router recovery PR: https://github.com/remix-run/react-router/pull/15032
• Previous plugin-rsc PR: https://github.com/vitejs/vite-plugin-react/pull/1223

Start by reading the existing experimental manager context and the linked plugin-rsc PR #1223, then review the related React Router issue and recovery PR. Compare deployment-specific base, manager-derived compatibility, and a stable manifest or version surface. Done means the project has a decided compatibility signal and documented ownership boundaries, if support is warranted.