Skip to content

fix(rsc): make unknown server references fail with a recognizable error - #1472

Open
agcty wants to merge 1 commit into
vitejs:mainfrom
agcty:fix-rsc-server-reference-not-found
Open

agcty wants to merge 1 commit into
vitejs:mainfrom
agcty:fix-rsc-server-reference-not-found

Conversation

@agcty

@agcty agcty commented Sep 26, 2026

Copy link
Copy Markdown

Description

In a build, src/rsc/shared.ts resolves a server reference with serverReferences[id]. Two things make an unknown id hard for a framework to handle:

  1. Inherited keys resolve. The registry is a plain object, so ids that name Object.prototype members do not reach the not-found branch: constructor "loads" (it calls the inherited Object constructor), and __proto__ or hasOwnProperty throw a TypeError from import_(). A request that only names an unknown id should always get the not-found error.
  2. The not-found error is only recognizable by its message. Frameworks want to answer an unknown server function id (a probe, or a client from an older deploy) with a 404 before reading the request body, and to report real load failures of known modules as server errors. Today the only way to tell them apart is to compare the message with server reference not found '<id>', after stripping the $$cache= tag the same way removeReferenceCacheTag does.

This PR looks the id up with Object.hasOwn and gives the not-found error a stable code: 'VITE_RSC_SERVER_REFERENCE_NOT_FOUND'. The message is unchanged, so anything matching on it keeps working.

Scope: the build path only. In dev, an unknown id is rejected earlier by the rsc:reference-validation plugin with its own error; I left that alone, since it already fails loudly. Happy to add the same code there if you want both paths to match.

Tests: this runtime file has no unit test harness, and I could not run the e2e suite in my environment. I checked the lookup logic in isolation (known id, missing id, __proto__, constructor, hasOwnProperty), and we run this exact change as a local patch in our framework's CI in the meantime. If you'd like an e2e case, point me to the fixture you prefer and I'll add one.

Related: #1337 and #1346 (route-aware server reference metadata). A has-reference check could come out of that work; this PR only makes the existing not-found error reliable and recognizable.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant