[BUG] new Request(request, init) crashes in route handlers with Invalid URL: [object Request]

[ama2369]

Bug: CustomRequest crashes with TypeError: Invalid URL: [object Object]

Description

OpenNext replaces globalThis.Request with CustomRequest, which passes input straight through to workerd's native Request via super(input, init).

workerd's Request constructor only accepts a string, URL, or Request instance. If it gets a plain object, it coerces it to a string ("[object Object]"), tries to parse that as a URL, and crashes. Node.js is more lenient and reads .url from plain objects, which is why this is workerd-specific.

Any code that does new Request({ url, method, headers, body }) triggers the crash (e.g. third-party middleware like Clerk).

Reproduction

The bug in two lines (works in Node.js, crashes in workerd):

const obj = { url: "https://example.com", method: "GET", headers: {}, body: null };
new Request(obj); // TypeError: Invalid URL: [object Object]

Full runnable worker

worker.js:

export default {
  async fetch(request) {
    const obj = { url: request.url, method: "GET", headers: {}, body: null };
    return new Response(new Request(obj).url);
  },
};

wrangler.jsonc:

{ "name": "repro", "main": "worker.js", "compatibility_date": "2024-09-23" }

npx wrangler dev && curl http://localhost:8787/
# → TypeError: Invalid URL: [object Object]

Fix

Before calling super(), check what input is. Strings, URLs, and real Request instances pass through directly. For plain objects, extract .url and merge method/headers/body into init so properties aren't lost:

const OriginalRequest = globalThis.Request;
const CustomRequest = class extends OriginalRequest {
  constructor(input: RequestInfo | URL, init?: RequestInit) {
    // ... existing cache/body fixes ...
    if (typeof input === "string" || input instanceof URL || input instanceof OriginalRequest) {
      super(input, init);
    } else {
      const req = input as unknown as Request;
      const merged = {
        method: req.method,
        headers: req.headers,
        body: req.body,
        ...(req.body ? { duplex: "half" as const } : {}),
        ...init,
      };
      super(req.url, merged as RequestInit);
    }
  }
};

Environment

• @opennextjs/cloudflare: 1.17.0
• Cloudflare Workers runtime (workerd)

[vicb]

workerd's Request constructor only accepts a string, URL, or Request instance. If it gets a plain object, it coerces it to a string ("[object Object]"), tries to parse that as a URL, and crashes. Node.js is more lenient and reads .url from plain objects, which is why this is workerd-specific.

That's not what I am seeing:

-> % node
Welcome to Node.js v22.21.1.
Type ".help" for more information.
> obj = { url: "http://localhost:8787/favicon.ico", method: "GET", headers: {}, body: null };
{
  url: 'http://localhost:8787/favicon.ico',
  method: 'GET',
  headers: {},
  body: null
}
> new Request(obj)
Uncaught TypeError: Failed to parse URL from [object Object]
    at new Request (node:internal/deps/undici/undici:9778:19) {
  [cause]: TypeError: Invalid URL
      at new URL (node:internal/url:827:25)
      at new Request (node:internal/deps/undici/undici:9776:25)
      at REPL2:1:1
      at ContextifyScript.runInThisContext (node:vm:137:12)
      at REPLServer.defaultEval (node:repl:593:22)
      at bound (node:domain:433:15)
      at REPLServer.runBound [as eval] (node:domain:444:12)
      at REPLServer.onLine (node:repl:926:10)
      at REPLServer.emit (node:events:531:35)
      at REPLServer.emit (node:domain:489:12) {
    code: 'ERR_INVALID_URL',
    input: '[object Object]'
  }
}

[ama2369]

You're right, Node.js also crashes with new Request(plainObject).

After more investigation, I think the actual issue is not about plain objects. In any Next.js API route on opennextjs-cloudflare, new Request(request, init) crashes. The request param that route handlers receive isn't recognized by workerd as a native Request instance, so workerd stringifies it to "[object Request]" and tries to parse that as a URL.

Reproduction (add to examples/playground15/app/api/clone-request/route.ts):

export async function GET(request: Request) {
  try {
    const newHeaders = new Headers(request.headers);
    newHeaders.set("x-test", "cloned");
    const cloned = new Request(request, { headers: newHeaders });
    return Response.json({ ok: true, url: cloned.url, test: cloned.headers.get("x-test") });
  } catch (e) {
    return Response.json({ ok: false, error: (e as Error).message }, { status: 500 });
  }
}

cd examples/playground15
pnpm preview
curl http://localhost:8787/api/clone-request
# {"ok":false,"error":"Invalid URL: [object Request]"}

Originally found via @better-auth/expo, whose onRequest hook clones the request with a modified origin header:

// @better-auth/expo/dist/index.mjs
async onRequest(request, ctx) {
    if (options?.disableOriginOverride || request.headers.get("origin")) return;
    const expoOrigin = request.headers.get("expo-origin");
    if (!expoOrigin) return;
    const newHeaders = new Headers(request.headers);
    newHeaders.set("origin", expoOrigin);
    return { request: new Request(request, { headers: newHeaders }) };
}

[vicb]

Now that rings a bell to me,
Could you please check the closed issues on this repo for something similar.
Ping me when you find something, we probably need to add something to troubleshooting section of the docs.

The repo is at https://github.com/opennextjs/docs if you feel like sending a PR :)

[ama2369]

@vicb Found some interesting issues. The closest prior issue is #201 ("[BUG] middleware http request method dropped"), also triggered by Clerk middleware and fixed in PR #202. Different specific bug in the same CustomRequest constructor: spreading init via { ...init } was dropping method.

#1037 ("[BUG] Expo Authorization Proxy returns 400") is still open and likely the same bug. Same library (@better-auth/expo), which is also how I originally hit this. No repro was posted but my reproduction above should cover it.

#859 ("[BUG] multiple request.clone in API routes") also involves request objects breaking in API route handlers, but was a different bug: workerd's clone() wasn't duplicating the body correctly. Fixed in workerd v1.20251008.0.

I also put up PR #1145 with a code fix if that's useful. Either way, happy to send a PR to the troubleshooting docs for this.

[vicb]

As I mentioned when I closed the related PR, I think this boils down to an issue in our workerd runtime.

I have created the following issue cloudflare/workerd#6700

Let's wait for the feedback there.