Move data fetching into FlightCard

[unstubbable]

How we got here (commits on main)

• Initial commit from Create Next App
• Remove default content from page
• Copy ai/rsc example from docs (i.e. https://sdk.vercel.ai/docs/concepts/ai-rsc#build-your-app)

Reproducing the issue (this PR)

When moving the data fetching from render into the FlightCard component, a race condition is triggered where, under certain circumstances, e.g. when starting the server with a production build, or when delaying the data fetching, the rendered element is unmounted again.

Here's how it should behave:

dev.mov

And here it's failing:

prod.mov

This is the RSC response for the successful run:

0:["$@1",["development",null]]
3:"$Sreact.suspense"
4:D{"name":"","env":"Server"}
1:["$@2",{"id":1710917980696,"display":["$","$3",null,{"fallback":"$undefined","children":"$L4"}]}]
2:{"0":[{"role":"user","content":"flight 42"}],"1":[{"role":"function","name":"get_flight_info","content":"TODO"}],"_t":"a"}
5:D{"name":"FlightCard","env":"Server"}
6:D{"name":"","env":"Server"}
4:["$","$3",null,{"fallback":"$L5","children":"$L6"}]
5:["$","div",null,{"children":[["$","h2",null,{"children":"Flight Information"}],["$","p",null,{"children":["Flight Number: ","42"]}],["$","p",null,{"children":["Departure: ","New York"]}],["$","p",null,{"children":["Arrival: ","San Francisco"]}]]}]
6:"$5"

And this is the RSC response for the failed run:

0:["$@1",["development",null]]
3:"$Sreact.suspense"
4:D{"name":"","env":"Server"}
1:["$@2",{"id":1710918908284,"display":["$","$3",null,{"fallback":"$undefined","children":"$L4"}]}]
2:{"0":[{"role":"user","content":"flight 42"}],"1":[{"role":"function","name":"get_flight_info","content":"TODO"}],"_t":"a"}
5:D{"name":"FlightCard","env":"Server"}
6:D{"name":"","env":"Server"}
4:["$","$3",null,{"fallback":"$L5","children":"$L6"}]
6:"$5"
5:["$","div",null,{"children":[["$","h2",null,{"children":"Flight Information"}],["$","p",null,{"children":["Flight Number: ","42"]}],["$","p",null,{"children":["Departure: ","New York"]}],["$","p",null,{"children":["Arrival: ","San Francisco"]}]]}]

Note that the last two RSC rows are switched here. When I add a breakpoint to setMessages, or delay the setter with a timeout, this response is also handled correctly, though.

[unstubbable]

I'm aware that this is not trivial to solve (one approach here), so there's a chance that this may be an anti-pattern.

[unstubbable]

But giving up colocation of data fetching in server components, when using them in an AI app (as shown in https://sdk.vercel.ai/docs/concepts/ai-rsc#nested-ui-streaming), would also be unfortunate.

[unstubbable]

Hm, interesting, this might be a bug in ReactFlightClient. For some reason, in the failed case, the last chunk ($5) is resolved as fulfilled, but having no value, and instead the rejectListeners as reason.

Failure:

Success:

[unstubbable]

Wait, shouldn't it be 6:"$L5" instead of 6:"$5", because that's really a lazy node?

[unstubbable]

Wait, shouldn't it be 6:"$L5" instead of 6:"$5", because that's really a lazy node?

Indeed, if I manually patch the response, the bug is fixed.

After having looked into https://github.com/vercel/ai/blob/main/packages/core/rsc/streamable.tsx and https://github.com/vercel/ai/blob/main/packages/core/rsc/utils.tsx, I'm not sure this can be fixed in ai/rsc.

It might instead be a bug in ReactFlightServer, maybe?

[unstubbable]

Ok, I think I've figured it out. The bug was introduced by facebook/react#28283. If I revert this change locally, the bug is fixed.

Reading the PR description and the added code comments, there doesn't appear to be a simple fix, as it would be required to track which rows have been emitted already to decide whether to use serializeLazyID or serializeByValueID.