[BUG]: Memory leak when http integration is enabled in Nestjs

[elton-okawa]

Tracer Version(s)

5.65.0

Node.js Version(s)

22.18.0

Bug Report

Problem

When http instrumentation is loaded, memory is not released

Might be related to: #5780

Setup

I'd found this issue during my work and I was able to create this minimal setup that replicated the exact scenario I'm facing, it has the following features:

• dd-tracer version 5.65.0
• node version 22.18.0
• Nestjs
• AppService, OtherService and DataRepository with scope.REQUEST
• AppService injects both OtherService and DataRepository
• AppService reads data from DataRepository and provides it to OtherService

Observations

• When http integration is disabled there's no leak
• When http integration is enabled there's a leak
• When http integration is enabled and OtherService releases provided data reference, there's no leak
• When http integration is enabled and using Node.js 24.7.0 there's no leak
  • Obs: there's no leak for the provided project but for the production one the leak still happens

Here's the heapsnapshot for each case (I couldn't upload directly to GitHub)

• Enabling/disabling http
• Using experimental async context

Workaround

Our current solution is releasing provided data reference from OtherService.

Reproduction Code

https://github.com/elton-okawa/dd-tracer-memory-leak

Error Logs

No response

Tracer Config

{"date":"2025-09-09T00:47:20.293Z","os_name":"Linux","os_version":"6.6.87.2-microsoft-standard-WSL2","architecture":"x64","version":"5.65.0","lang":"nodejs","lang_version":"22.18.0","service":"ddtracer-leak","agent_url":"http://127.0.0.1:8126","debug":false,"sampling_rules":[],"tags":{"service":"ddtracer-leak","version":"0.0.1","runtime-id":"188dc337-673d-4e0b-b877-1db2706a57b0","_dd.rc.client_id":"cf8ef65f-088a-4be3-9f53-7c400f8ea362"},"dd_version":"0.0.1","log_injection_enabled":true,"runtime_metrics_enabled":true,"profiling_enabled":false,"integrations_loaded":["http"],"appsec_enabled":false,"agent_error":"connect ECONNREFUSED 127.0.0.1:8126"}

Operating System

Linux

Bundling

Unsure

[kusham]

i would love to take a look this..assigned to me

[BridgeAR]

It seems like this does not happen when using Node.js 24. @elton-okawa could you please verify that?

[elton-okawa]

It seems like this does not happen when using Node.js 24. @elton-okawa could you please verify that?

@BridgeAR You're right, I've just confirmed that it doesn't happen in Node.js 24.7.0, it's still not a LTS version though.
I'll update the description.

[elton-okawa]

@BridgeAR just a small update, using Node.js 24.7.0 there's no leak for the small project I provided but the leak still happens for the production one.

[BridgeAR]

@elton-okawa yes, I just checked and it seems to be related to the AsyncContextFrame handling in Node.js.

If you start your production Node.js version with --experimental-async-context-frame, the memory leak will be gone.

It does seem to be an issue in Node.js therefore, while I do not know if we could work around the issue. This needs further investigation.