Request with ReadableStream body causes 'expected non-null body source' assertion failure in undici 7.x

[satyam-mishra-pce]

Environment

• Node.js: v24.14.0 (undici 7.21.0)
• Platform: macOS 26.4 (Apple Silicon)

Description

In undici 7.x, creating a Request with a ReadableStream body causes an assertion failure:

Error: expected non-null body source

This is a breaking change from undici 6.x (Node 22 and earlier) where this worked fine.

Reproduction

const body = new TextEncoder().encode(JSON.stringify({ test: true }));

// Create original Request with Uint8Array body
const originalReq = new Request('https://example.com', {
  method: 'POST',
  body,
  headers: { 'Content-Type': 'application/json' }
});

// Read the body as ReadableStream
const bodyStream = originalReq.body;

// Create new Request from ReadableStream (common pattern in middleware/proxies)
const newReq = new Request(originalReq.url, {
  method: originalReq.method,
  headers: originalReq.headers,
  body: bodyStream,
  duplex: 'half',
});

// Try to fetch with the new request
await fetch(newReq);
// → Error: expected non-null body source

Root Cause

In undici/lib/web/fetch/index.js, there's an assertion:

if (request.body != null) {
  assert(request.body.source != null)
  request.body = safelyExtractBody(request.body.source)[0]
}

When a Request is created with a ReadableStream body (instead of Uint8Array, string, etc.), the body.source property is null, causing the assertion to fail.

Impact

This breaks legitimate use cases:

• Middleware that re-creates requests (e.g., Next.js's fetch patching, proxies)
• Libraries that create intermediate Request objects (e.g., @atproto-labs/fetch-node for SSRF protection)

Expected Behavior

Creating a Request with a ReadableStream body should work, as it did in undici 6.x (Node 22).

Workaround

Downgrade to Node.js 22 (undici 6.x) or pre-read the body as ArrayBuffer before creating the new Request.

Question

Is this strict assertion intentional? If so, what's the recommended pattern for middleware that needs to re-create Request objects?

[mcollina]

I traced this to the 401 authentication retry path, not the redirect assertion quoted in the issue body.

Short version:

• ReadableStream request bodies have body.source === null by design.
• The exact expected non-null body source error was introduced by fix websocket basic auth #4747 (33885134), merged on 2026-01-19 and first shipped in v7.19.0.
• That change added 401 retry/auth handling plus an isTraversableNavigable() stub that returned true, which made Node enter a browser-only 401 retry branch.
• Once in that branch, stream-backed request bodies hit request.body.source == null and throw makeNetworkError('expected non-null body source').

So the regression was introduced in #4747 / v7.19.0, and the proper fix is #4941 (4f4bf4f1), merged on 2026-04-07.

One important note: the exact error message here strongly suggests a 401 path. By itself, the redirect assertion in the issue description does not explain expected non-null body source.

[satyam-mishra-pce]

Thank you for the detailed analysis! 🙏

This confirms our workaround was the right approach. We've pinned to Node.js 22.x (undici 6.24.1) to avoid the bug, which matches our production environment on Vercel.

We'll monitor for Node.js 24.x releases with the fix from PR #4941 and upgrade once available.