[BUG] cacheComponents: true permanent "Connection closed" error with blank static shell served

[mahalrs]

Describe the bug

When cacheComponents: true is enabled in next.config.ts (Next.js 16.2.4), the OpenNext Cloudflare only serves static shell (static pages and Suspense fallbacks) without streaming the dynamic content inside suspense. This results in all pages being permanently broken and the browser throws Error: Connection closed.

Related to #1115

Steps to reproduce

1. Create a Next.js 16.2.4 app with cacheComponents: true
2. Have an async Server Component wrapped in <Suspense>:

async function StreamedContent() {
  const user = await getUser() // async operation
  return <div>user.name</div>
}

export default function Page() {
  return (
    <div>
      <div>
          Some content...
      </div>
      <Suspense fallback={<div>Loading...</div>}>
          <StreamedContent />
      </Suspense>
    </div>
  )
}

3. Build and deploy with @opennextjs/cloudflare
4. Page shows blank static shell with "Some content..." and "Loading..." but the actual <StreamedContent/> never renders in the browser. Browser throws Error: Connection closed.

Expected behavior

1. The cached static shell should be sent as the first chunk of a streaming response, rendering "Some content..." and "Loading...".
2. The Worker should then initiate dynamic rendering for the Suspense boundaries and render the <StreamedContent/> showing user name.
3. The browser receives the Suspense fallback HTML but never gets resolution data
4. The browser throws Error: Connection closed when the response stream ends
5. The page remains stuck on the loading fallback permanently

@opennextjs/cloudflare version

1.19.1

Wrangler version

4.83.0

next info output

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.1.0: Mon Oct 20 19:32:41 PDT 2025; root:xnu-12377.41.6~2/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 24.9.0
  npm: 11.6.0
  Yarn: 1.22.19
  pnpm: 10.17.0
Relevant Packages:
  next: 16.2.4 // Latest available version is detected (16.2.4).
  eslint-config-next: N/A
  react: 19.2.5
  react-dom: 19.2.5
  typescript: 5.9.3
Next.js Config:
  output: N/A

Additional context

No response

[vicb]

This is most probably the same as #1223 (comment)

[takakikasuga]

i have just faced same issue otherwise below config...

next.config.ts

import type { NextConfig } from "next";

const config: NextConfig = {
  cacheComponents: true,
};

export default config;

import { initOpenNextCloudflareForDev } from "@opennextjs/cloudflare";

initOpenNextCloudflareForDev();

open-next.config.ts

export default defineCloudflareConfig({
  incrementalCache: r2IncrementalCache,
  queue: doQueue,
  tagCache: d1NextTagCache,
  enableCacheInterception: false
});

[ehellman]

Okay, so. We've also gotten this error in 1.19.1 and Next 16.2.4.

I went down a rabbit hole and tried to find the cause of this and while I can't spend any more time on this I do have 2 fixes that I have tested as patches which situationally solves this problem, but we still have other issues such as the Cloudflare Worker hanging after a while. We can even reproduce it somewhat in preview-mode where we get the "worker hung" error.

Disclaimer: I am unfamiliar with the codebase of both the AWS and Cloudflare packages, so take these findings and suggestions with a grain of salt. Hopefully someone who knows the bigger picture here can see if this is right or wrong.

Finding 1 - PPR shell cache returns empty Flight payload, breaking $RS hydration

Looking at the original types in Next.js for rscData:

• CachedAppPageValue
• IncrementalCachedAppPageValue

We can see that rscData is actually Buffer | undefined. This does not match the types declared in the adapter, which is just Buffer.

A PPR shell page where the flight payload lives in the segment data, not on the parent page itself. Next.js writes a cache entry where rscData is undefined. The shell is valid, the interactive bits are keyed separately under segmentData.

@opennextjs/aws@3.10.1 doesn't handle that case correctly in two places. The cache adapter assumes rsc/rscData is always defined, and the cacheInterceptor happily emits an empty body when no matching segmentData is found.

The browser receives a zero-length Flight payload, the PPR Suspense reveal helper ($RS) can't reconcile the placeholder with the (missing) resolved tree, and hydration throws "Node.removeChild: The node to be removed is not a child of this node".

Apart from updating the type itself, here's what I did:

// cache.ts:getIncrementalCache
          return {
            lastModified: _lastModified,
            value: {
              kind: "APP_PAGE",
              html: cacheData.html,
              // rscData: Buffer.from(cacheData.rsc), <--- old
			  rscData: cacheData.rsc ? Buffer.from(cacheData.rsc) : undefined,
              status: meta?.status,
              headers: meta?.headers,
              postponed: meta?.postponed,
              segmentData,
            },
          } as CacheHandlerValue;

and

// cache.ts:set
            await globalThis.incrementalCache.set(
              key,
              {
                type: "app",
                html,
                // rsc: rscData.toString("utf8"), <--- old
                rsc: rscData ? rscData.toString("utf8") : undefined,
                meta: {
                  status,
                  headers,
                  postponed,
                },
                revalidate,
                segmentData: segmentData ? segmentToWrite : undefined,
              },
              "cache",
            );

Since the rscData type can now be undefined, I also had to make some changes to the cacheInterceptor.

  // dist/core/routing/cacheInterceptor.js - generateResult()
  if (cachedValue.type === "app") {
    isDataRequest = Boolean(event.headers.rsc);
    if (isDataRequest) {
      const { body: appRouterBody, additionalHeaders: appHeaders } =
        getBodyForAppRouter(event, cachedValue);
      if (appRouterBody === undefined) {
        // no rsc to serve and no matching segmentData. signal cache miss so
        // the caller falls through to the renderer instead of emitting an
        // empty flight payload (which would break client-side $RS hydration).
        return undefined;
      }
      body = appRouterBody;
      additionalHeaders = appHeaders;
    } else {
      body = cachedValue.html;
    }
    // ...
  }

  // dist/core/routing/cacheInterceptor.js - cacheInterceptor() switch
  case "app":
  case "page": {
    const result = await generateResult(
      event, localizedPath, cachedData.value, cachedData.lastModified,
    );
    // generateResult returns undefined when the cache entry can't satisfy
    // the request (e.g. PPR shell with no rsc and no matching segmentData).
    // fall through to the renderer in that case
    return result ?? event;
  }

  // dist/adapters/cache.js) - read path (~line 124)
  return {
    lastModified: _lastModified,
    value: {
      kind: "APP_PAGE",
      html: cacheData.html,
  -   rscData: Buffer.from(cacheData.rsc),
  +   rscData: cacheData.rsc != null ? Buffer.from(cacheData.rsc) : undefined,
      status: meta?.status,
      headers: meta?.headers,
      postponed: meta?.postponed,
      segmentData,
    },
  };

  // dist/adapters/cache.js) - write path (~line 232)
  await globalThis.incrementalCache.set(key, {
    type: "app",
    html,
  - rsc: rscData.toString("utf8"),
  + rsc: rscData != null ? rscData.toString("utf8") : undefined,
    meta: {
      status,
      headers,
      postponed,
      ...
    },
  });

The ?? event would then work as the mechanism for falling through, returning the original event tells the caller "no cache hit, continue with normal rendering."

[ehellman]

Finding 2 - workerd reorders ReadableStream chunks bigger than 4096 bytes, corrupting RSC streams

When Next.js streams a PPR response, it emits a sequence of chunks, interleaved SSR HTML for resolved Suspense boundaries and <script>self.__next_f.push([...])</script> tags carrying Flight rows. Each __next_f.push(...) chunk must be received intact:
the script body is a JSON-stringified array, and a missing tail is unparseable.

In workerd, the Web --> Node bridge that backs cloudflare-node.js's wrapper has a bug: when a ReadableStream chunk is larger than 4096 bytes, the runtime splits it and delivers the remainder out of order, after one or more subsequent chunks have already been written. For a Flight push tag larger than 4096 bytes:

chunk N    : <script>self.__next_f.push([1,"...4053 bytes..." <- no closing
chunk N+1  : <div hidden id="S:1">...resolved Suspense HTML...</div> <- jumps the queue
chunk N+2  : ...rest..."])</script> <- the missing tail

This can happen when:

1. A chunk has to be bigger than 4096 bytes.

workerd's Web to Node bridge only splits chunks above 4 KiB. Below that, chunks pass through whole and in order, no reorder, no problem!

Flight pushes are JSON-serialized RSC data, so the size scales with what's actually inside the boundary:

• Small static content: tiny push, often well under 4 KiB
• Product card grids, search results, deeply-nested components with lots of props: easily multi-KB

If your page never emits a push above 4096 bytes, you never trip the split path.

2. Some other chunk has to arrive before the reordered tail.

A reorder is only visible when something else slots into the gap. If the timeline of chunks is roughly sequential (one big resolved tree, no Suspense interleaving), the bridge can split all it wants and the tail still arrives in the right place because nothing else is competing for that slot.

Multiple or nested Suspense boundaries change this. While React is still flushing the tail of boundary A's Flight push, boundary B finishes resolving and Next emits its <div hidden id="S:N"> SSR block plus its own $RS reveal. That's the chunk that jumps the queue and gets stuffed into the unclosed <script> tag from A.

Conclusion

We didn't manage to fix the problem fully, but the 500-page and "Connection closed" errors on cold starts disappeared mostly.

[conico974]

PPR doesn't work with cacheInterception. It will only be fully compatible with the adapter API

[ehellman]

@conico974 sorry, I should have clarified that the fix for finding 1 is actually the undefined handling of rscData for the read/write paths in cache.ts

// cache.ts:getIncrementalCache
          return {
            lastModified: _lastModified,
            value: {
              kind: "APP_PAGE",
              html: cacheData.html,
              // rscData: Buffer.from(cacheData.rsc), <--- old
			  rscData: cacheData.rsc ? Buffer.from(cacheData.rsc) : undefined,
              status: meta?.status,
              headers: meta?.headers,
              postponed: meta?.postponed,
              segmentData,
            },
          } as CacheHandlerValue;

and

// cache.ts:set
            await globalThis.incrementalCache.set(
              key,
              {
                type: "app",
                html,
                // rsc: rscData.toString("utf8"), <--- old
                rsc: rscData ? rscData.toString("utf8") : undefined,
                meta: {
                  status,
                  headers,
                  postponed,
                },
                revalidate,
                segmentData: segmentData ? segmentToWrite : undefined,
              },
              "cache",
            );

Updating my comment with that info, the changes to cacheInterceptor just came about because of the typechange on rscData where we now would have to handle undefined for it.