Allow CI Workflow Run

• approve CI run for commit: 5f3bc6798896e03e668bfb620ca95f76a810a805

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

Excellent fix for a tricky edge case! 🎯

Problem Identified:
When cacheComponents: true is enabled and notFound() is thrown inside a Suspense boundary, the RSC stream was being sent directly without detecting the HTTP access fallback error, causing "Connection closed" errors on the client.

Solution Approach:
Your fix properly consumes the entire RSC stream first to detect HTTP access fallback errors (like notFound()), then:

• If no errors → sends the buffered RSC data as before
• If HTTP error detected → falls through to full dynamic render to properly display the error page

Strengths:
✅ Comprehensive test coverage with two test cases covering different scenarios
✅ Proper error detection by checking reactServerErrorsByDigest
✅ Maintains backward compatibility for non-error cases
✅ Sets correct HTTP status codes
✅ Clean fallback to dynamic rendering when needed

Minor Suggestions:

1. Performance consideration: Buffering the entire RSC stream in memory (chunks array) could be memory-intensive for large responses. Consider adding a comment about this trade-off or exploring streaming detection if possible.

2. Code comment clarity: The comment "We need to consume the RSC stream first..." is great, but could also mention why we can't detect this during streaming (because Suspense boundaries can catch errors).

3. Test robustness: Consider adding a test case for a large page to ensure the buffering approach doesn't cause memory issues.

Overall, this is a solid fix for a complex streaming + error handling interaction! 🚀

We are experiencing this and it is pretty much a deal killer for being able to use cache components as it essentially means we can have any working 404 behavior on pages. Hoping @Rani367's fix makes it into the next release soon.

import { notFound } from 'next/navigation'

export default async function ArticlePage({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params
  const article = await findArticle(slug)
  
  if (!article) {
    notFound() // results in connection closed and error page instead of 404
  }
  
  return <article />
}

Hi @gnoff, could you take a look at this PR when you have a chance? There are users blocked by this issue (see #86251 and the comment above from @dsbrianwebster) who can't use cacheComponents with notFound(). Happy to address any feedback. Thanks!

Updated the fix to also store HTTP access fallback errors in reactServerErrorsByDigest (in create-error-handler.tsx), which is needed for the detection logic in app-render.tsx to work correctly.

@Rani367 thanks for the updates. I've been communicating about this to Vercel through support ticket for an upcoming project. Hopefully that helps pull in some senior eyes from the NextJS team on this. Broken 404 behavior is a pretty critical concern, especially for SEO.

IMO, if this is a known limitation of cache components in their current form, this really feels like a broader, production-blocking issue, not just for us, but for other teams evaluating cache components for real-world deployments, and one deserving of some priority attention, or a return to an experimental flag disclaimer to opt in to cache components.

🤞 For this to get reviewed and merged soon.

Any updates on this?

Any updates on this?

@wyattjoh ?