Race condition in Node.js middleware body cloning still causing production errors despite PR #85418

[arvinxx]

Race condition in Node.js middleware body cloning still causing production errors despite PR #85418

Link to the code that reproduces this issue

lobehub/lobe-chat#10309

To Reproduce

1. Deploy a Next.js 16 application with Node.js runtime middleware
2. Use tRPC or similar frameworks that read request body in route handlers
3. Send requests with moderate-sized payloads (>50KB) or trigger multiple tool calls
4. The error occurs intermittently, especially under load or with concurrent requests

Current vs. Expected behavior

Current behavior:

The application throws TypeError: Response body object should not be disturbed or locked intermittently in production, even after implementing the commonly suggested req.clone() workaround:

Error Stack:

⨯ TypeError: Response body object should not be disturbed or locked
    at new NextRequest (.next/server/chunks/10404.js:4220:14)
    at NextRequestAdapter.fromNodeNextRequest (.next/server/chunks/10404.js:3770:16)
    at handler (.next/server/app/(backend)/trpc/lambda/[trpc]/route.js:618:127)

For chat endpoint:

⨯ TypeError: Response body object should not be disturbed or locked
    at new NextRequest (.next/server/chunks/10404.js:4220:14)
    at NextRequestAdapter.fromNodeNextRequest (.next/server/chunks/10404.js:3770:16)
    at handler (.next/server/app/(backend)/webapi/chat/[provider]/route.js:569:53)

Expected behavior:

Request body should be properly cloned and finalized before being passed to route handlers, with no race conditions causing stream state inconsistencies.

Provide environment information

Operating System:
  Platform: linux (Docker)
  Version: Docker image lobehub/lobe-chat:2.0.0-next.89
Binaries:
  Node: v20.x
  pnpm: 9.x
Relevant Packages:
  next: 16.0.1
  react: 19.0.0
  react-dom: 19.0.0
Next.js Config:
  output: standalone
  runtime: nodejs (middleware)

Which area(s) are affected?

Middleware, App Router, tRPC integration

Which stage(s) are affected?

Production (Docker standalone mode), also reproducible in development with sufficient load

Additional context

Background

We are running LobeChat (https://github.com/lobehub/lobe-chat) in production with Docker using Next.js 16's standalone output mode. We implemented the commonly suggested workaround of cloning requests in our auth middleware and tRPC handlers:

// Our attempted fix in auth middleware
export const checkAuth = (handler: RequestHandler) => async (req: Request, options: RequestOptions) => {
  const clonedReq = req.clone();  // This doesn't solve the issue
  // ...
  return handler(clonedReq, { ...options, jwtPayload });
};

// Our attempted fix in tRPC handlers
const handler = (req: NextRequest) => {
  const preparedReq = prepareRequestForTRPC(req);  // Using req.clone()
  return fetchRequestHandler({
    req: preparedReq,
    // ...
  });
};

However, this workaround does NOT solve the problem.

Root Cause Analysis

After investigating Next.js source code and related issues (#83453, #85416), we identified that the problem occurs in Next.js's internal body cloning mechanism:

The race condition happens here:

// packages/next/src/server/next-server.ts (Line ~1757)
} finally {
  if (hasRequestBody) {
    requestData.body.finalize();  // ❌ Missing await!
  }
}

The finalize() method is async but not awaited:

// packages/next/src/server/body-streams.ts
export interface CloneableBody {
  finalize(): Promise<void>  // Returns a Promise
  cloneBodyStream(): Readable
}

Timeline of the race condition:

T0: Request arrives, body cloning starts
    └─ cloneBodyStream() creates PassThrough streams

T1: Middleware processes with cloned stream

T2: Middleware completes
    └─ finalize() called WITHOUT await ❌

T3: Route handler immediately tries to read req.body
    └─ Original stream may still be transferring data

T4: finalize() still executing in background
    └─ replaceRequestBody() not yet completed

T5: undici detects disturbed stream state
    └─ Throws "Response body object should not be disturbed or locked"

Why Application-Level req.clone() Doesn't Work

The issue occurs before our application code runs:

1. Next.js internally calls cloneBodyStream() when passing request to middleware
2. The finalize() is called without await, leaving the stream in an inconsistent state
3. By the time our req.clone() executes, the underlying stream is already corrupted
4. Cloning a corrupted Request object doesn't fix the underlying stream issue

Reproduction Characteristics

• ✅ Consistently fails: Large payloads (>350MB) or multiple concurrent requests
• ⚠️ Intermittently fails: Medium payloads (50KB-350MB) depending on server load
• ❌ Rarely fails: Small payloads (<50KB) due to fast stream completion
• 📊 Hardware dependent: Threshold varies based on CPU/network performance (as noted in Race condition with Node.js middleware body cloning #85416)

Impact on Production

This issue causes:

• Random 500 errors for end users
• Failed chat completions mid-conversation
• Failed model list fetches
• Degraded user experience
• No reliable workaround at application level

Related Issues & PR

• Response body object should not be disturbed or locked" error with Node.js middleware and large request bodies #83453 - Original report with large file uploads
• Race condition with Node.js middleware body cloning #85416 - Detailed race condition analysis
• fix(nodejs-middleware): await for body cloning to be properly finalized #85418 - PR with fix (merged to canary but not released)

The fix in PR #85418 is simple but critical:

} finally {
  if (hasRequestBody) {
-   requestData.body.finalize();
+   await requestData.body.finalize();
  }
}

Request

1. Urgent release: Please include the fix from PR fix(nodejs-middleware): await for body cloning to be properly finalized #85418 in the next patch release (16.0.2)
2. Documentation: Add a warning in the migration guide about this issue
3. Workaround guidance: Provide official guidance for users stuck on 16.0.1

Temporary Workaround

For others affected by this issue, the only reliable workaround is to patch Next.js:

Create .patches/next@16.0.1.patch:

diff --git a/dist/server/next-server.js b/dist/server/next-server.js
--- a/dist/server/next-server.js
+++ b/dist/server/next-server.js
@@ -1241,7 +1241,7 @@ class NextNodeServer extends _baseserver.default {
                 });
             } finally{
                 if (hasRequestBody) {
-                    requestData.body.finalize();
+                    await requestData.body.finalize();
                 }
             }
         } else {

Reference in package.json:

{
  "pnpm": {
    "patchedDependencies": {
      "next@16.0.1": "patches/next@16.0.1.patch"
    }
  }
}

---

Note: This issue affects any production application using:

• Node.js runtime middleware (not Edge runtime)
• Request body reading in route handlers
• Frameworks like tRPC, Server Actions with file uploads, or custom API routes
• Moderate to large request payloads

The fix is already merged but not yet released, causing production issues for many users who have upgraded to Next.js 16.

[github-actions]

We could not detect a valid reproduction link. Make sure to follow the bug report template carefully.

Why was this issue closed?

To be able to investigate, we need access to a reproduction to identify what triggered the issue. We need a link to a public GitHub repository (template for App Router, template for Pages Router), but you can also use these templates: CodeSandbox: App Router or CodeSandbox: Pages Router.

The bug template that you filled out has a section called "Link to the code that reproduces this issue", which is where you should provide the link to the reproduction.

• If you did not provide a link or the link you provided is not valid, we will close the issue.
• If you provide a link to a private repository, we will close the issue.
• If you provide a link to a repository but not in the correct section, we will close the issue.

What should I do?

Depending on the reason the issue was closed, you can do the following:

• If you did not provide a link, please open a new issue with a link to a reproduction.
• If you provided a link to a private repository, please open a new issue with a link to a public repository.
• If you provided a link to a repository but not in the correct section, please open a new issue with a link to a reproduction in the correct section.

In general, assume that we should not go through a lengthy onboarding process at your company code only to be able to verify an issue.

My repository is private and cannot make it public

In most cases, a private repo will not be a sufficient minimal reproduction, as this codebase might contain a lot of unrelated parts that would make our investigation take longer. Please do not make it public. Instead, create a new repository using the templates above, adding the relevant code to reproduce the issue. Common things to look out for:

• Remove any code that is not related to the issue. (pages, API routes, components, etc.)
• Remove any dependencies that are not related to the issue.
• Remove any third-party service that would require us to sign up for an account to reproduce the issue.
• Remove any environment variables that are not related to the issue.
• Remove private packages that we do not have access to.
• If the issue is not related to a monorepo specifically, try to reproduce the issue without a complex monorepo setup

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps by opening a new issue.

I think my reproduction is good enough, why aren't you looking into it quickly?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues