Cannot construct a Request with a Request object that has already been used

[radum]

Hello,

Next.js: 14.2.2
DDTrace: 5.11.0
Node: 20.11.1
Running on AWS EKS pods

We just upgraded to version 5.11.0 and our Next.js internal API routes that are using fetch to get data from external services are now failing with Cannot construct a Request with a Request object that has already been used.. Disabling datadog or reverting to the previous version (5.10.0) works fine.

I will try to see if I can setup a demo repo but its very unlikely I can strip down our setup.

We load DD via "start": "node -r ./server-preload.js ./node_modules/.bin/next start" and in that file we have:

function setUpDatadogTracing() {
	const tracer = require('dd-trace');

	tracer.init({
		runtimeMetrics: true,
		logInjection: true,
		// env: 'dev', 		// This is set on the POD automatically via DATADOG_ENV=
		// service: '',		// This is set on the POD automatically via DD_SERVICE=
		// version: packageJSON?.version ?? 'unknown'		// This is set on the POD automatically via DD_VERSION=
	});
	tracer.use('next');
}

setUpDatadogTracing();

Not sure what changed but looks like fetch constructor is called twice from DD and then within our app it fails to construct it again.

[cannontrodder]

We have seen this on the 4.x.x release line, unfortunately we needed this to get a fix related to an out of memory race condition on the auto injection docker image

[yjukaku]

We are also seeing the same issue on 4.x, and Next.js 13.x

fetch fails with an error when making a POST with a body to our backend. We think it fails only when the server responds with a redirect (ours is using a 307).

[radum]

@yjukaku That is very interesting, have you found an workaround for it?

[Klaitos]

Same issue here, lost few hours to land on this issue.

TypeError: Cannot construct a Request with a Request object that has already been used.
at node:internal/deps/undici/undici:12618:11

[cannontrodder]

Looks like this commit is designed to fix it: 0f36e48

[yjukaku]

Our workaround, other than downgrading the DD library, was to update the URLs we were fetching to avoid the redirect.

EDIT: It seems the redirects were likely a red herring and it didn't help to update the URLs to avoid the redirect.

[StephaneBischoffVasco]

Having this issue with our Docker image
Reverted back to COPY --from=datadog/dd-lib-js-init:v5.10.0 /operator-build/node_modules /dd_tracer/node/
For now.

[mdnorman]

We ran into this as well. Even though we're pinning the versions of datadog-lambda-extension and datadog-lambda-js, the Lambda layer was still picking up a newer version of dd-trace that had this problem.

[tbauer428]

Ran into this same error with next-auth using dd-trace in our Dockerfile, we had dd-trace@^5, which pulled in v5.11.0.

Downgrading to v5.9.0 immediately alleviated the issue.

[juancarlosjr97]

Same issue here, and we are pinning to v5.10.0 for now.

[olafurw]

Seems a fix has existed for a couple of days but hasn't been pushed out yet #4258

[KevinVR]

Can confirm - issue on 5.11.0, while 5.10.0 works fine.

We need PR #4258 also for v5, not only pre-v6.

[EmiiFont]

Ran into this same error with auth0 node sdk package using dd-trace

Downgrading to v5.10.0 fixed the issue.

[rkstamm]

Same here. Caused our next.js server side fetches to fail all over. Storing a local copy of the wrapper using specific versioning to 5.10, and from now on. Thanks @radum for finding this. We spent hours trying to figure out why this suddenly happened.

[oachoor]

can confirm as well (nestjs), downgrading to v5.10.0 for now

[anddreluis2]

if you remove the connection to apm the app works again

[tlhunter]

A fix for this has been released in v5.12.0, v4.36.0, and v3.57.0 of the library. Please upgrade to confirm that it fixes the issue. If it does not fix the issue please @ me and I'll reopen this issue and we'll investigate further. Thanks!

[juancarlosjr97]

Nice! Looks like it is working :)