--trace-leaks doesn't show any tracing information

[dandv]

Version: Deno 2.1.4 (and probably earlier) - 2.1.9

import { assert } from '@std/assert';

async function culprit() {
  const connection = await Deno.connect({
    port: 80,
    hostname: "example.com",
  });
  return connection.localAddr.port;
}

function intermediary() {
  return culprit();
}

Deno.test('foo', async () => {
  const localPort = await intermediary();
  assert(localPort);
});

$ deno test --trace-leaks --allow-net bug.ts
running 1 test from ./bug.ts
foo ... FAILED (252ms)

 ERRORS 

foo => ./bug.ts:15:6
error: Leaks detected:
  - A TCP connection was opened/accepted during the test, but not closed during the test. Close the TCP connection by calling `tcpConn.close()`.

 FAILURES 

foo => ./bug.ts:15:6

FAILED | 0 passed | 1 failed (256ms)

error: Test failed

I expected to see some sort of tracing information mentioning intermediary and culprit.

[dandv]

I added sanitizeResources: false to the outermost describe of that test, which encompasses all tests, and got this different trace, so --trace-leaks does work in some situations:

[test name] => https://jsr.io/@std/testing/1.0.9/_test_suite.ts:256:10
error: Leaks detected:
  - An async operation to connect to a TCP server was started in this test, but never completed. This is often caused by not awaiting a `Deno.connect` call. The operation was started here:
    at op_net_connect_tcp (ext:core/00_infra.js:250:13)
    at Object.connect (ext:deno_net/01_net.js:583:61)
    at TCP.#connect (ext:deno_node/internal_binding/tcp_wrap.ts:291:10)
    at TCP.connect (ext:deno_node/internal_binding/tcp_wrap.ts:139:25)
    at _internalConnectMultiple (node:net:352:24)
    at defaultTriggerAsyncIdScope (ext:deno_node/internal/async_hooks.ts:193:18)
    at GetAddrInfoReqWrap.emitLookup [as callback] (node:net:631:7)
    at GetAddrInfoReqWrap.onlookupall [as oncomplete] (node:dns:54:8)
    at ext:deno_node/internal_binding/cares_wrap.ts:71:9
    at eventLoopTick (ext:core/01_core.js:177:7)

I don't see any reference to my code in that stack trace, so I have no idea where to start investigating the leak, since it only happens in about 1 in 50 tests.