🐛 BUG: wrangler unstable_dev - fetch fails to parse URL from Request object

[ianduvall]

Which Cloudflare product(s) does this pertain to?

Wrangler core

What version(s) of the tool(s) are you using?

3.12.0 [Wrangler]

What version of Node are you using?

18.17.1

What operating system are you using?

Mac

Describe the Bug

Testing a worker using unstable_dev fails to parse URL when using a Request object.

Example:

// example.test.ts
import { type UnstableDevWorker, unstable_dev } from 'wrangler';

describe('worker', () => {
	let worker: UnstableDevWorker;
	beforeAll(async () => {
		worker = await unstable_dev('src/index.ts', {
			logLevel: 'debug',
			experimental: { disableExperimentalWarning: true },
		});
	});
	afterAll(async () => {
		await worker.stop();
	});

	test('example', async () => {
		const baseUrl = `http://${worker.address}:${worker.port}`;
		const url = new URL('/path', baseUrl);
		url.searchParams.set('hello', 'world');
		const request = new Request(url, {
			method: 'DELETE',
			headers: { something: 'goes here' },
		});
		console.log(url.toString(), request.url);

		// fails here
		const response = await worker.fetch(request);
		expect(response.status).toBe(404);
	});
});

Please provide a link to a minimal reproduction

See example code above

Please provide any relevant error logs

Jest output:

 FAIL  tests/failing.test.ts
  worker
    ✕ example (18 ms)

  ● worker › example

    TypeError: Failed to parse URL from [object Request]

      24 |
      25 |              // fails here
    > 26 |              const response = await worker.fetch(request);
         |                                            ^
      27 |              expect(response.status).toBe(404);
      28 |      });
      29 | });

      at new Request (../../node_modules/.pnpm/wrangler@3.12.0/node_modules/wrangler/wrangler-dist/cli.js:12652:19)
      at parseRequestInput (../../node_modules/.pnpm/wrangler@3.12.0/node_modules/wrangler/wrangler-dist/cli.js:152859:19)
      at Object.fetch (../../node_modules/.pnpm/wrangler@3.12.0/node_modules/wrangler/wrangler-dist/cli.js:152819:14)
      at Object.fetch (tests/failing.test.ts:26:33)

    Cause:
    TypeError: Invalid URL

      24 |
      25 |              // fails here
    > 26 |              const response = await worker.fetch(request);
         |                                            ^
      27 |              expect(response.status).toBe(404);
      28 |      });
      29 | });

      at new Request (../../node_modules/.pnpm/wrangler@3.12.0/node_modules/wrangler/wrangler-dist/cli.js:12650:25)
      at parseRequestInput (../../node_modules/.pnpm/wrangler@3.12.0/node_modules/wrangler/wrangler-dist/cli.js:152859:19)
      at Object.fetch (../../node_modules/.pnpm/wrangler@3.12.0/node_modules/wrangler/wrangler-dist/cli.js:152819:14)
      at Object.fetch (tests/failing.test.ts:26:33)

[forgeDeepakBalasubramanian]

As a workaround, I believe you should be able to pass in the URL and headers directly into the fetch
ie.
const resp = await gatewayWorker.fetch("www.test.com", { headers: { Cookie: "country_code=us", }, });

[mikedidomizio]

I believe the Failed to parse URL from [object Request] issue is related to this one and this one. This comment explains the issue in detail.

This is the line that gives the error, which is Request from undici.

I tried also using a Request from undici@5.20.0 in my test, but had no luck.

I was curious and returned the request from the wrangler package like so:

  // dev.ts

  // returns the Request object
  request: Request,
  fetch: async (input?: RequestInfo, init?: RequestInit) => {
...

I could therefore ensure both Request objects were equal, and in my test I tried:

  worker = await unstable_dev("main.js", {
      experimental: { disableExperimentalWarning: true },
  });
  // create a new Request object from the Request from Wrangler
  const req = new worker.request(`http://example.com`);

  // pass their Request into them
  const resp = await worker.fetch(req);

and it works as expected ✅. Anyways not a solution, but figured I'd share what I found.

(Tested via node@16.17.0 and node@18.18.2)