Problem
Frameworks built on @vitejs/plugin-rsc need to handle RSC deployment skew.
A common failure mode is:
- A user has an old browser tab open.
- A new deployment goes live.
- The old tab sends an RSC navigation, route-discovery request, or server action to the new server.
- 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:
- Frameworks use deployment-specific
base for coarse skew recovery only.
- Frameworks derive a compatibility version from the existing experimental
manager.
@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
Problem
Frameworks built on
@vitejs/plugin-rscneed to handle RSC deployment skew.A common failure mode is:
Frameworks can own the recovery behavior themselves. For example, React Router can return a
204reload 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:
If a deployment makes Vite
basedeployment-specific, thenbasecan 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:
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:
This would let a framework distinguish:
Question
Should
@vitejs/plugin-rscsupport compatibility-aware recovery as a first-class concept?If yes, what surface should frameworks use?
Possible directions:
basefor coarse skew recovery only.manager.@vitejs/plugin-rscexposes or documents a stable compatibility primitive, such as a finalized compatibility version or manifest.The intent is not for
@vitejs/plugin-rscto 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