** Disclaimer** This information might be inaccurate, due to it being generated automatically
This appears to be related to the RSC rendering implementation in @storybook/nextjs. The issue likely stems from the RSC rendering logic in @storybook/nextjs/dist/preview.js where React Server Components are handled. Key steps to fix: 1. Modify the RSC rendering wrapper in @storybook/nextjs to prevent re-renders by: - Adding a cache or memoization layer for async RSC results - Implementing proper boundary conditions for async component resolution 2. The specific implementation would need to be in the RSC experimental feature code, likely in: js // @storybook/nextjs/src/experimental-react-server // Add caching/memoization for async RSC results const cachedRSCResult = new WeakMap(); if (cachedRSCResult.has(Component)) { return cachedRSCResult.get(Component); } This appears to be a regression introduced in 8.5.0+ related to how RSC async boundaries are handled.

Upon further testing, it seems to be happening on older versions (~8.4.7) as well for this specific minimal repro 🤔

For the best context on my original concern, the way I discovered it is by experimenting with the issue outlined here on the newest release of Storybook: amannn/next-intl#771 (reply in thread).

• In both versions, using await getTranslations() as the very first statement works
• In 8.4.7, attempting to use await getTranslations() as the second await fails with "context not found"
• In 8.5.0, attempting to use await getTranslations() as the second await fails with the infinite re-render

In this specific example, both await methods are actually synchronous (one is being mocked to return a data object directly, the other one is being mocked to call a client-side hook instead of server-only method).

Hence me opening this issue. There is probably a lot more underground currents here re: RSC/Suspense/etc that I am not seeing, so just trying to provide as much info as possible to help isolate and troubleshoot here.

Hi @dmitrc,

Thanks for posting the issue. I read through the next-intl thread as well, and the behavior is indeed pretty strange. I try to take a look the next days.

Hi @dmitrc,

Thanks for posting the issue. I read through the next-intl thread as well, and the behavior is indeed pretty strange. I try to take a look the next days.

Thanks @valentinpalkovic,
I have now updated the linked repro to include the whole next-intl setup for your convenience.

• LocalizedComponentTranslationsFirst renders fine
• LocalizedComponentTranslationsLater throws context error on 8.4.x and infinite re-renders on 8.5.x

Also added some other components to play around with, including async no await and fake await (actually sync).

Please let me know if I can clarify anything further or help in any way!
Thanks again for looking into it!

	LocalizedComponentTranslationsFirst	LocalizedComponentTranslationsLater
8.5.0
8.4.7

@dmitrc @valentinpalkovic

Looks like the promise now needs to be cached otherwise each render of the rsc/action in storybook returns a new promise object causing the infinite render loop.

Likely a duplicate of #30033

See my comment there on #30033

Here is the diff between next.js v15.0.4-canary.26 and v15.0.4-canary.27

In my environment, I've isolated the regression behavior in storybook to this change. In other words when I revert my Next.JS version to v15.0.4-canary.26 it works. When I upgrade to v15.0.4-canary.27 it starts failing as the OP described.

This Next.JS diff includes a React upgrade from 19.0.0-rc-380f5d67-20241113 to 19.0.0-rc-b01722d5-20241114.

Here is the diff for those react versions which represents going from React RC 0 to React RC 1.

Here is a post about React 19 RC 1 from the React team.

It seems the big difference is that the React 19 enableSiblingPrerendering feature flag is switched to true. Not sure yet how or why this affects Storybook the way it does: causing infinite Suspense loops in RSC components.

Thanks for looking into it, @boylec!

It seems there are two distinct issues described in this thread:

• Async RSC in infinite render loop (related to Suspense concurrency changes you have highlighted), tracked in [Bug]: Failed to render Async Component(RSC) with Next 15.1 #30033.

• Some weird behavior wrt "losing" upstream context when a hook is called after the first await (see the next-intl part of my repro, it was like that for a long while now, before becoming an infinite render loop in 8.5.0).

Acknowledging that Storybook's handling of RSC is kind of funky to begin with, do we know if recent changes to Storybook contributed to these latest problems? Or are these entirely due to upgrading the version of React?

I don't know the problem of losing the upstream context of the latter...
As for the infinite rendering loop, we confirmed that the situation did not change even when the Storybook version was changed during the investigation of #30033, and that only the Next.js version (React version) was having an effect.

@dmitrc I have a hunch that the losing of the upstream context is related to the RSC infinite suspense issue, although I don't have proof.

Considering the example provided by @davidcarr-au:

Expected:
* Uncached initial render begins
* Uncached suspends due to 'use' hook invocation with a promise
* This promise causes suspense, and becomes part of the upstream React context in some way.
* Uncached render cycle re-runs... eventually the promise resolves or rejects and the render cycle is allowed to proceed past the point of that use hook.

Potential Actual:
* Uncached initial render begins
* Uncached suspends due to 'use' hook invocation with a promise
* This promise causes suspense, and becomes part of the upstream React context in some way.
* The component's context is being wiped for some reason at this point, its likely this promise is being wiped as well
* Uncached render cycle re-runs and a new promise is instantiated each time the 'use' hook is invoked (considering the original one is wiped), resulting in an infinite suspense loop.

@davidcarr-au 's 'Cached' example works because the promise's lifetime is not dictated by the component's context.

EDIT: In hindsight, I would expect that the behavior of the Uncached component in @davidcarr-au 's example is by design. If you call the 'use' hook with a newly instantiated promise on each invocation, it should be expected to suspend infinitely. I think one should always pass the same instance to the 'use' hook if one expects it to eventually exit the suspense state.

@boylec

Digging deeper (specifically the infinite render issue in React 19-rc1), here’s my understanding:

Pre-RC1:
React would render the nodes below the Suspense boundary along with the fallback. When the Promise resolved, React replaced the fallback with the resolved content. Since the child components retained the same context and memoized props, everything worked as expected. No new Promises were instantiated during this process.

RC1:
React now renders the fallback immediately and pre-warms the child nodes in parallel to fetch data asynchronously. However, if the child nodes generate new Promises during this pre-fetching step (e.g., due to unstable async functions), React re-suspends the boundary. This triggers a re-render, which creates a new Promise, leading to an infinite loop.

This is not exclusive to the new 'use' hook, same deal with rendering nested async components using the traditional await data-fetching pattern inside a Suspense boundary. Each render instantiates a new Promise, destabilizing the boundary and causing React to repeatedly suspend and re-render.

In Nextjs, server actions make this behaviour stable by resolving data on the server, preventing the client from generating new Promises during rendering. However, Storybook doesn’t have this advantage, as it runs purely client-side, exposing issues with unstable async functions or Promises.

So we can use promises and async components like we did pre-rc1 within storybook, but it requires a stabilisation mechanism, hence why the example i provided worked, i've resorted to running calls through a middleware to cache the promise and then remove it on first re-request when mocked for storybook.

FYI the React docs also highlight this caveat: client-side Promises recreated on each render will cause unnecessary re-suspends:
https://react.dev/reference/react/use#caveats

I am very confused, is there any workaround other than waiting for the Storybook fix?

This sample was created from an idea, but it can render some Async Component.

The problem is the case where the parent is also a Server Component and the Async Component is used as an inner component.
In this case, the Component seen from the outside is not an Async Component, so Promise cannot be taken out.

const sleep = (msec: number) => new Promise(resolve => setTimeout(resolve, msec))

const InsideComponent = async () => {
  await sleep(100)
  return (
    <p>inside</p>
  )
}

export const OutsideComponent = () => {
  return (
    <div>
      <InsideComponent /> {/*<- failed to render this component*/}
    </div>
  )
}

Any more than this may require intervention in the internal renderer rather than the decorator

https://gist.github.com/NEKOYASAN/f6e192194169bb9f22e8cb2ef2c84eca

I think the correct fix for this is going to require internal renderer work. Seems like storybook needs to legitimately run a server-side render using react-dom/server against stories for frameworks that use React 19 RC 1+ such as Next.JS, then pipe that raw server HTML to react-dom/client hydrateRoot against the same story to get the final render. Or some variation like that.

I'm not well-versed in the internals of storybook enough to make this contribution with the short time I have available.

Thanks for the example @NEKOYASAN

Unfortunately it doesn't get us by so we're stuck on next.js 15.0.4-canary.26 until RSCs get fixed permanently in storybook.

You're probably right @boylec. We are booked up through 9.0, but I will discuss with the team to try to get it in as soon as we can manage it. If anybody wants to flex their RSC muscles and try to give this a shot, we are more than happy to advise.

Thank you for your advice @NEKOYASAN

Although it's a bit of a workaround, I avoided the issue by creating a package.json in a subdirectory and fixing the Next.js version that Storybook internally depends on to v15.0.4

.storybook/main.js
sb/package.json // Next.js v15.0.4
package.json // Next.js v15.1.6

// sb/package.json
{
  "name": "subdirectory storybook",
  "scripts": {
    "storybook": "storybook dev --config-dir ../.storybook"
  },
  "devDependencies": {
    "next": "15.0.4",
    "storybook": "8.4.7"
  }
}

// package.json
{
  "name": "project",
  "scripts": {
    "storybook": "yarn --cwd sb storybook"
  },
  "devDependencies": {
    "next": "15.1.6",
    "storybook": "8.4.7"
    ...
  }
}

Since the Next.js code used within Storybook depends on the packages installed in the runtime environment, this solution works.
It's not ideal, but I wanted a quick solution since Next.js v15.1.2 includes security updates.

I knew it...
I'm currently developing on a new RSC-based framework, so I will see if there is any way I can contribute.

At the moment there is no need to client references like in the RSC-based framework, and as @boylec wrote, it seems like a combination of renderToReadableStream and hydrateRoot can be support it.
It may not be something that can be fixed immediately….

You're probably right @boylec. We are booked up through 9.0, but I will discuss with the team to try to get it in as soon as we can manage it. If anybody wants to flex their RSC muscles and try to give this a shot, we are more than happy to advise.

@shilman I'm going to spend a few days on it and see how things go. Is Discord the best place to reach out if I need a tip or two?

@boylec That's amazing. Yeah on SB discord there's a #contributing channel for help but also feel free to DM or @ me. I often have trouble keeping up!

@boylec That's amazing. Yeah on SB discord there's a #contributing channel for help but also feel free to DM or @ me. I often have trouble keeping up!

@shilman just fyi I'm blocked on running local sandbox against Next.JS prerelease due to a separate bug. @zhyd1997 has apparently addressed this issue with PR #30372 which is awaiting review. This would unblock me to move forward if it resolves the issue there.

@boylec I just DMed @valentinpalkovic to see if he can merge. Bedtime here! I can look in the morning if it's still open

@boylec I just DMed @valentinpalkovic to see if he can merge. Bedtime here! I can look in the morning if it's still open

Ah okay thanks. Actually I'll just pull in his changes locally until merged, so no biggie if it takes awhile. Thank you guys!

renderToReadableStream & hydrateRoot approach trying in #30419.
This approach seems to work fine for now, but there may be some problems or potential bugs.

I just downgraded Next.js to 15.0.4 and Storybook to 8.4.7 and it works, thx @kawamt .

I'm gonna wait for a better solution, thankfully my project doesn't rely on last updates of the framework and the library.

using react 18 with vite without nextjs was also causing this on local development. not on production though. so we also downgraded it to v8.4.7

@iamswain25 Do you have a reproduction you can share?

@iamswain25 Do you have a reproduction you can share?

we were manually triggering suspense by throwing an empty promise. I'll try my best.