fix(ext/node): implement dns Resolver cancel() and timeout support

[bartlomieju]

Summary

• Implements ChannelWrap.prototype.cancel() which aborts all pending DNS queries with ECANCELLED error code.
• Wires up the timeout option in the Resolver constructor to race DNS queries against a timer, returning ETIMEOUT on expiry.
• Passes timeout to the underlying hickory DNS resolver so queries complete promptly instead of running with hickory's default 5s timeout.
• Enables 4 Node.js compat tests: parallel/test-dns-cancel-reverse-lookup.js, parallel/test-dns-channel-cancel.js, parallel/test-dns-channel-cancel-promise.js, parallel/test-dns-channel-timeout.js

Test plan

• ./x test-compat test-dns-channel — all 3 pass
• ./x test-compat test-dns-cancel-reverse-lookup passes

[bartlomieju]

Note: test-dns-cancel-reverse-lookup.js requires getHostByAddr (dns.reverse) from #33579. This PR should land after #33579.

[fibibot]

The substantive logic looks right — cancel() walks #pendingQueries and dispatches ECANCELLED to each pending req.oncomplete, the per-query add/has-and-delete pattern around every queryX correctly suppresses late-arriving completions after cancel, and the Promise.race-against-setTimeout pattern surfaces ETIMEOUT when the resolver runs long. The Rust-side opts.timeout = Duration::from_millis(ms.max(1)) plumbing into hickory is the right place to actually bound the underlying query. Glad to see the assert_success_err debug_assert! cleanup made it in here too — exactly the simplification I suggested on #33579.

CI is red on lint though (3 platforms, format-only — the opts.timeout = line in ext/net/ops.rs needs to wrap onto a single line). Per my own gate I shouldn't APPROVE while CI is red — going COMMENT until that lands.

Three substantive notes inline (none blocking the format fix; the format itself is the only CI blocker).

[fibibot]

Format blocker — rustfmt wants this on one line (current diff has opts.timeout = and Duration::from_millis(...) on separate lines):

opts.timeout = std::time::Duration::from_millis(ms.max(1));

Fails on all three lint platforms: https://github.com/denoland/deno/actions/runs/25009734436/job/73242045807. ./tools/format.js will auto-fix.

Separate substantive note while we're here: forcing opts.attempts = 1 whenever timeout_ms is set diverges from Node's Resolver({ timeout, tries }) contract — Node treats tries and timeout as independent (timeout per attempt, multiplied by tries). With this PR, any caller passing both gets a single attempt regardless of tries. The four target tests don't exercise the tries > 1 + timeout combo so they pass, but a faithful Node port would respect both. Worth a TODO comment here at minimum.

[fibibot]

The cancel-handle approach in e4a548fd is much cleaner than my clearTimeout suggestion — using core.createCancelHandle() + core.tryClose(cancelRid) actually aborts the underlying op rather than just dropping the result, and the Deno.errors.Interrupted → "ETIMEOUT" mapping in the catch is the right shape. Also nice: dropped the timeout_ms field from the public ResolveDnsOption struct entirely (addressed my soft-API concern), and the EXPECTED_VIOLATIONS bump to 3 accounts for the new core.tryClose calls.

But CI went red — test node_compat debug linux-aarch64 is failing on test-dns-cancel-reverse-lookup.js (flaky on runs 0+1, then 10002ms timeout, then fail). Detail inline.

Also worth checking: the linux: false skip was removed for all four enrolled tests, but the cancel tests don't exercise the timeout cancel-handle path — they call resolver.cancel() (no timeout set), which means cancelRid is undefined and the underlying op runs to hickory's natural timeout. The user-facing callback fires ECANCELLED via the cancel() loop, but the still-running op keeps the test's event loop alive. That's likely what's producing the 10s hang.

[fibibot]

cancel() only walks #pendingQueries and fires req.oncomplete("ECANCELLED", []) synchronously — it doesn't actually abort the underlying op_dns_resolve. For the timeout path the cancel handle does abort the op, but here (no timeout set) the op stays alive until hickory's own timeout (~5s default × attempts) fires.

Failure pattern in CI on linux-aarch64 (https://github.com/denoland/deno/actions/runs/25011070179/job/73247390033):

[Warning] node_compat::parallel::test-dns-cancel-reverse-lookup.js was flaky on run 0
[Warning] ... was flaky on run 1
test test-dns-cancel-reverse-lookup.js has been running for more than 60 seconds
test test-dns-cancel-reverse-lookup.js ... fail (10002ms)

The user-facing callback fires ECANCELLED immediately, but the orphaned op_dns_resolve keeps the test's event loop alive until hickory times out. The 10002ms pretty clearly aligns with hickory's default 5s × 2 attempts.

Fix: extend the cancel-handle pattern to all queries, not just the timeout path. Roughly — give every #query call a cancelRid up front, store it on the req (or in a parallel map), and have cancel() core.tryClose each one in addition to (or instead of) firing oncomplete. Something like:

#cancelRids: Map<QueryReqWrap, number> = new Map();

// in #query, always create a cancelRid:
const cancelRid = core.createCancelHandle();
this.#cancelRids.set(req, cancelRid);  // populated by caller

// cancel():
for (const [req, rid] of this.#cancelRids) {
  core.tryClose(rid);
  req.oncomplete("ECANCELLED", []);
}
this.#cancelRids.clear();
this.#pendingQueries.clear();

The op should then return Deno.errors.Interrupted and the existing catch in #query will short-circuit, so the test's event loop can drain.

(There may be additional issues if req.oncomplete("ECANCELLED", []) doesn't get mapped through dnsException to set .code/.syscall/.hostname correctly in the test's assertion — worth verifying that string code passes through the existing dispatch, since dnsException is typically built around integer error codes.)

[bartlomieju]

This is already addressed in the current code -- cancel() now walks #cancelRids and calls core.tryClose(rid) on each one (lines 748-751), in addition to firing oncomplete("ECANCELLED", []) on pending queries. Every #query call creates a cancel handle via core.createCancelHandle() (line 305), stores it in #cancelRids (line 306), and cleans it up on completion (lines 312, 339). So orphaned op_dns_resolve calls are properly aborted and the event loop can drain.

[fibibot]

Removing linux: false from these four entries is the right end-state, but at least test-dns-cancel-reverse-lookup.js is still failing on linux-aarch64 in this commit (10s hang → fail per the inline above). Either restore the platform skip for that one entry temporarily, or block this PR on the underlying fix. The other three (channel-cancel, channel-cancel-promise, channel-timeout) appear to pass — channel-timeout shows up green in the test log (test-dns-channel-timeout.js ... ok (141ms)).

[lunadogbot]

LGTM -- read the cancel/timeout flow end-to-end:

• #pendingQueries: Set<QueryReqWrap> is added/checked-then-deleted at every query* entrypoint and inside every .then(...). The cancel() iterates and calls req.oncomplete('ECANCELLED', []), then clear()s. The double-fire race is handled correctly: a late-resolving promise hits if (!this.#pendingQueries.has(req)) return after cancel cleared the set, so the original oncomplete is skipped.
• The timeout path sets up a core.createCancelHandle() and a setTimeout that calls core.tryClose(cancelRid). The op throws Deno.errors.Interrupted, the catch maps it to code = 'ETIMEOUT'. The finally clears the timer and closes the rid in either order (timer-fired-first vs op-completed-first), and the cancelRid !== undefined guard prevents a double-close.
• The new code type is string | number. Verified against dnsException in internal/errors.ts:376 -- it explicitly handles both: if typeof code === 'number' it does getSystemErrorName, otherwise the string code passes through to ex.code. So 'ECANCELLED' and 'ETIMEOUT' produce the right shape on the user-facing error.
• The IPv4-mapped IPv6 expansion at line 678+ for reverse-lookup correctly turns ::ffff:1.2.3.4 into the two 16-bit hex groups.

One tiny note: in ext/node/ops/dns.rs, swapping if code == 0 { return DnsError::Io(...) } for debug_assert!(code != 0, ...) is a strict improvement in debug builds, but in release builds the unreachable case becomes a silent fall-through to whatever match code returns next (probably an arm that doesn't match -> generic UNKNOWN). Worth either a comment confirming the caller really can't pass 0 (the function name assert_success_err suggests that's the contract), or unreachable!() instead of debug_assert!() so release builds at least panic with a clear message rather than producing a misleading mapping. Not blocking.