dns.lookup: pending promises grow unboundedly under sustained EAI_AGAIN load

Version

v24.14.1

Platform

Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 (Debian forky/sid)

Subsystem

dns

What steps will reproduce the bug?

When dns.promises.lookup() is called repeatedly for a hostname that triggers EAI_AGAIN (e.g. a nonsense TLD like 'asd'), getaddrinfo blocks its libuv thread for ~10 seconds before rejecting. Under sustained load, new lookups queue behind the blocked threads and the number of unresolved promises grows without bound.

In our production system this manifests as a memory leak: each pending promise holds references to the calling closure (in our case, per-conversation config objects), and none of them can be GC'd until getaddrinfo eventually returns.

Minimal reproduction — save as repro.mjs:

import { lookup } from 'node:dns/promises';

const HOSTNAME = 'asd'; // triggers EAI_AGAIN
const INTERVAL_MS = 2000;
const TOTAL = 50;

let pending = 0;
let started = 0;
let settled = 0;

function fire() {
  const id = ++started;
  ++pending;
  const t0 = Date.now();
  console.log(`[#${id}] started  (pending: ${pending})`);

  lookup(HOSTNAME).then(
    (result) => {
      --pending;
      ++settled;
      console.log(`[#${id}] resolved ${result.address} after ${Date.now() - t0}ms  (pending: ${pending})`);
    },
    (err) => {
      --pending;
      ++settled;
      console.log(`[#${id}] rejected ${err.code} after ${Date.now() - t0}ms  (pending: ${pending})`);
    }
  );
}

const interval = setInterval(() => {
  if (started >= TOTAL) {
    clearInterval(interval);
    return;
  }
  fire();
}, INTERVAL_MS);

setInterval(() => {
  console.log(`\n--- status: started=${started} settled=${settled} pending=${pending} ---\n`);
}, 5000).unref();

setTimeout(() => {
  console.log(`\n=== FINAL: started=${started} settled=${settled} stuck=${pending} ===`);
  if (pending > 0)
    console.log(`LEAK CONFIRMED: ${pending} lookup(s) never settled.`);
  else
    console.log('No leak detected.');
  process.exit(pending > 0 ? 1 : 0);
}, TOTAL * INTERVAL_MS + 60_000);

Run:

node repro.mjs

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior? Why is that the expected behavior?

Each lookup() call should resolve or reject in bounded time, regardless of the hostname. Under sustained load, the number of pending (unresolved) promises should stay bounded — ideally proportional to the libuv thread pool size (UV_THREADPOOL_SIZE, default 4), not to the total number of requests issued.

What do you see instead?

• Each getaddrinfo call for 'asd' blocks a libuv thread for ~10 seconds before rejecting with EAI_AGAIN.
• Only ~2 rejections return per 10-second cycle (thread pool saturation).
• New lookups queue behind the blocked threads, so the pending count grows monotonically: 5 → 8 → 11 → 14 → 17 → 20 → …
• Promises are never settled until their turn comes, which under continuous load may be never.

Sample output (trimmed):

[#1] started  (pending: 1)
[#2] started  (pending: 2)
[#3] started  (pending: 3)
[#4] started  (pending: 4)
[#5] started  (pending: 5)
[#6] started  (pending: 6)
[#1] rejected EAI_AGAIN after 10031ms  (pending: 5)
[#7] started  (pending: 6)
[#2] rejected EAI_AGAIN after 10014ms  (pending: 5)

--- status: started=7 settled=2 pending=5 ---

[#8] started  (pending: 6)
...
[#12] started  (pending: 9)
[#4] rejected EAI_AGAIN after 16024ms  (pending: 8)

--- status: started=12 settled=4 pending=8 ---

...
[#32] started  (pending: 21)
[#12] rejected EAI_AGAIN after 40068ms  (pending: 20)

--- status: started=32 settled=12 pending=20 ---

The pending count never converges to zero. In a long-running server, this is effectively a memory leak because every queued promise retains references to its enclosing closure.

Additional information

• UV_THREADPOOL_SIZE is unset (default 4).
• The callback-based dns.lookup() shows the same behavior — this is a libuv/getaddrinfo issue, not specific to the promises API.
• Hostnames that fail fast (e.g. ENOTFOUND) do not exhibit this problem.
• The EAI_AGAIN timeout (~10s per attempt) appears to come from the system resolver's retry/timeout settings, but the queuing behind the fixed-size thread pool is what makes it unbounded.
• A possible mitigation from Node's side: support AbortSignal in dns.lookup() / dns.promises.lookup() so callers can cancel stale lookups, or expose a configurable per-lookup timeout.

首先使用 node 运行提供的 repro.mjs，并观察在反复出现 EAI_AGAIN 失败和默认 UV_THREADPOOL_SIZE 下 dns.promises.lookup() 的行为。将其与基于 callback 的 dns.lookup() 进行比较，然后检查 node:dns/promises 和 dns.lookup 入口点。完成标准是需要一种经过约定和测试的方法，防止未解析的 lookup 无限增长，例如 issue 中讨论的取消或 timeout 行为。