udp: report a failed connect() as the socket error, not a getaddrinfo error

[robobun]

Problem

• On Windows, every connect() failure behind Bun.udpSocket({ connect }) is thrown as a DNS error: Bun.udpSocket({ connect: { hostname: "::1", port: 1 } }) rejects with DNSException: connect ENOTFOUND ::1 (code: "ENOTFOUND"). The name resolved fine; it was connect() that failed. Linux reports the real reason, EAFNOSUPPORT (the default socket is IPv4). Same misreport for WSAEADDRNOTAVAIL (connect to 0.0.0.0), WSAEFAULT, WSAENETUNREACH, and so on. Reproduces with the 1.4.0 release and a canary at eabb96d.
• bsd_connect_udp_socket (packages/bun-usockets/src/bsd.c:1831) returns -1 when connect() fails and a getaddrinfo code when resolution fails. udp_socket.rs ran the -1 through errno_sys() first (src/runtime/socket/udp_socket.rs:50), whose Windows branch returns None for every non-zero value, so the -1 went on to c_ares::Error::init_eai(), whose Windows fallback arm (src/cares_sys/c_ares.rs:1797) is ENOTFOUND.
• The connect() method that node:dgram's socket.connect() calls (js_connect, udp_socket.rs:1919) has the same two-namespace return value and handled neither: -1 became a bare Error: Failed to connect socket with no code on every platform (Node gives connect ENETUNREACH 224.0.0.1:1 with code, syscall, address, port), and a getaddrinfo status was not checked at all, so the socket was marked connected.

Fix

• One check_connect() in udp_socket.rs interprets the status for both callers: -1 reads the socket error (WSAGetLastError() on Windows, errno elsewhere); any other non-zero value is a getaddrinfo code and keeps going through init_eai. The Winsock read is the one get_us_error() (the setsockopt and send wrappers) already did, split out as last_socket_error() so both share it; errno_sys() is removed, its only other caller was get_us_error's POSIX branch.
• bsd_connect_udp_socket captures the connect() error before freeaddrinfo() and re-installs it, so the value the caller reads is the one connect() produced (and an empty result list reports EAFNOSUPPORT instead of a stale value).
• node:dgram decorates the error like Node's ExceptionWithHostPort (connect EAFNOSUPPORT ::1:1, .address, .port, .syscall), reusing the helper the send path already had for this (decorateSendError, now decorateHostPortError).
• Why this is right: the error a user gets back names the call that failed. The -1 / getaddrinfo split is the contract of the function being called; reading -1 as a getaddrinfo code was never valid, it just happened to be masked on POSIX because errno_sys claimed the -1 first. For node:dgram, the resulting shape is Node's (the code is the kernel's: Node reports the family mismatch as EINVAL because it parses the literal itself; kernel-level failures such as ENETUNREACH match Node exactly).
• Tests: test/js/bun/udp/udp_socket.test.ts (connect option failures) and test/js/bun/udp/dgram.test.ts (connect() failure ...). Against the unfixed canary: on Windows x64, 2 udp_socket tests fail (DNSException instead of Error) and both dgram tests fail (code undefined); on Linux, both dgram tests fail and the udp_socket tests pass, since that path was already correct there (the Windows-only 0.0.0.0 -> EADDRNOTAVAIL case is the second distinct Winsock code, showing the code is read from the failed call). With the fix: udp_socket.test.ts 208 pass on Linux, 209 on Windows; dgram.test.ts 63 pass on Linux, 50 pass / 13 pre-existing skips on Windows.
• Also run with the fix on Linux: the 17 ported test-dgram-connect*, test-dgram-send-*error*, test-dgram-error-message-address, test-dgram-custom-lookup, test-dgram-blocklist node tests, and udp_socket_recv_flags.test.ts.
• Behavior change besides the codes: socket.connect() in node:dgram now fails (with a DNSException) when the address it is handed does not resolve, where it previously reported success. node:dgram resolves names before calling it, so this is only reachable through a custom lookup returning something unparsable.
• Related but distinct: udp: report an unresolvable bind hostname as a getaddrinfo error #37707 (bind path, unresolvable hostname) and udp: resolve a hostname to the same address on the bind and connect side #38588 (which address a name connects to; it also rewrites bsd_connect_udp_socket and establishes the same errno contract, so whichever lands second takes that version of the function).

Background

• getaddrinfo() reports failures through its return value (EAI_* codes, positive on macOS and Windows, negative on glibc), not through errno. connect() returns -1 and reports through errno, or WSAGetLastError() on Windows, where the CRT errno is not touched by Winsock calls. bsd_connect_udp_socket resolves and then connects, so its single int return carries both kinds of result and -1 is the only value that means "look at the socket error".
• init_eai maps an EAI_* code to the c-ares error Bun uses for DNS exceptions; on Windows any value it does not recognise becomes ENOTFOUND, which is how a -1 turned into a DNS error.
• ExceptionWithHostPort is the error Node's dgram builds for bind/send/connect failures: message <syscall> <code> <address>:<port> plus code, errno, syscall, address, port properties. Bun's dgram.ts keeps the native error (its code is already platform-correct) and sets those fields on it.
• Connecting a UDP socket only records the peer; it fails immediately for an address the socket's family cannot carry, which is why an IPv4 socket connecting to ::1 is a deterministic, offline failure usable as a fixture (Linux and Windows say EAFNOSUPPORT; the BSDs may check the sockaddr length first and say EINVAL, so the tests accept either).

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 23 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 14e6936a-1df2-4117-b11c-7cfbe60765f1

📥 Commits

Reviewing files that changed from the base of the PR and between 2f5c180 and 05cc773.

📒 Files selected for processing (5)

• packages/bun-usockets/src/bsd.c
• src/js/node/dgram.ts
• src/runtime/socket/udp_socket.rs
• test/js/bun/udp/dgram.test.ts
• test/js/bun/udp/udp_socket.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Status: fix pushed, waiting on CI.

Reproduced on Windows x64 with the 1.4.0 release and the canary at eabb96d: Bun.udpSocket({ connect: { hostname: "::1", port: 1 } }) rejects with DNSException: connect ENOTFOUND ::1, and dgram socket.connect(1, "::1") reports a codeless Failed to connect socket (the latter on Linux too). With this branch the same calls report EAFNOSUPPORT / connect EAFNOSUPPORT ::1:1, and connect to 0.0.0.0 on Windows reports EADDRNOTAVAIL.

Tests: test/js/bun/udp/udp_socket.test.ts (connect option failures) and test/js/bun/udp/dgram.test.ts (connect() failure ...); both files verified failing on the unfixed build (Windows: both files; Linux: dgram.test.ts) and passing with the fix on Linux and Windows x64.

[github-actions]

This PR may be a duplicate of:

1. udp: resolve a hostname to the same address on the bind and connect side #38588 - Rewrites the same bsd_connect_udp_socket in packages/bun-usockets/src/bsd.c with the identical errno fix (drop the bare return -1, track last_error across the connect loop, re-install it after freeaddrinfo), so the native half of this change is duplicated work and the two versions of the function conflict directly.

🤖 Generated with Claude Code

[claude]

I reviewed this PR and didn't find any bugs. It's a well-scoped fix, but it reworks cross-platform errno/WSA handling across the C↔Rust boundary and changes user-visible error behavior for node:dgram connect(), so a human look would still be worthwhile — especially given the noted overlap with #38588 on bsd_connect_udp_socket.

What was reviewed:

• bsd_connect_udp_socket: LIBUS_ERR captures errno/WSAGetLastError immediately after connect() and is re-installed after freeaddrinfo; the result == NULL case now yields EAFNOSUPPORT via the same path.
• check_connect's -1 vs getaddrinfo-code split: EAI_BADFLAGS == -1 on glibc, but hints.ai_flags is zeroed so it isn't reachable; macOS/Windows EAI codes don't collide with -1.
• get_us_error refactor preserves the existing POSIX == -1 / Windows < 0 semantics; the removed errno_sys was file-local (no other callers).
• address_z.as_bytes() excludes the trailing NUL (ZBox::as_bytes vs as_bytes_with_nul), so the DNS-error hostname isn't NUL-padded.

Extended reasoning...

Overview

The PR fixes UDP connect() error reporting so a failed connect(2) surfaces its actual errno instead of being misclassified as a DNS ENOTFOUND (Windows) or a codeless Error: Failed to connect socket (node:dgram on all platforms). It touches:

• packages/bun-usockets/src/bsd.c — bsd_connect_udp_socket now captures the last connect() error before freeaddrinfo() and re-installs it via errno/WSASetLastError; an empty getaddrinfo result reports EAFNOSUPPORT rather than a stale value.
• src/runtime/socket/udp_socket.rs — removes the file-local errno_sys shim, splits get_us_error into failure detection + a shared last_socket_error reader, and adds check_connect that both connect callers (Bun.udpSocket({connect}) and node:dgram's js_connect) use to interpret the two-namespace return (0 / -1 / EAI code).
• src/js/node/dgram.ts — generalizes decorateSendError → decorateHostPortError(err, syscall, address, port) and applies it to the connect error path so .syscall/.address/.port/.message match Node's ExceptionWithHostPort.
• New tests in udp_socket.test.ts and dgram.test.ts covering the IPv4→::1 family mismatch (deterministic offline), the Windows-only 0.0.0.0 → EADDRNOTAVAIL case, and the node:dgram callback + 'error'-event shapes.

Security risks

None identified. This is error-classification plumbing on already-failed syscalls; no new inputs are parsed, no privilege boundaries crossed, no resource allocation added.

Level of scrutiny

Moderate. The diff is small and the mechanism is very clearly explained, but it sits squarely in the "Cross-platform" and "Error handling" review categories: platform-gated C (#ifdef _WIN32), platform-gated Rust (#[cfg(windows)]), errno preservation across a libc call, and Winsock's separate error slot. It also changes user-visible behavior (node:dgram's socket.connect() now fails on an unresolvable address where it previously reported success). None of that is mechanical enough to auto-approve.

Other factors

• Verified LIBUS_ERR expands to WSAGetLastError()/errno (internal.h:80,84) and (int)LIBUS_SOCKET_ERROR is -1 on both platforms, so the capture-then-reinstall in bsd.c is sound and check_connect's -1 arm matches on Windows too.
• Checked the glibc EAI_BADFLAGS == -1 collision: hints is zeroed (no ai_flags), so getaddrinfo cannot return it here; macOS/BSD EAI codes are positive and Windows uses WSA-range values, so -1 is unambiguously the connect-failure sentinel.
• Confirmed the removed errno_sys was local to this file (its only remaining caller was get_us_error's POSIX arm, now inlined as res == -1); other errno_sys hits in the tree are unrelated definitions.
• ZBox::as_bytes() excludes the trailing NUL (util.rs:157 vs the separate as_bytes_with_nul at :174), so the hostname passed into error_to_js_with_syscall_and_hostname is clean — and this call site already existed pre-PR for the Bun.udpSocket({connect}) path.
• The PR flags an upcoming conflict with #38588 on the same C function; that coordination is a reason on its own for a maintainer to look before merging.

[robobun]

Not a duplicate of #38588, though the two touch the same C function.

• udp: resolve a hostname to the same address on the bind and connect side #38588 changes which address a name connects to (and how a dual-stack socket addresses IPv4). It leaves the bug fixed here in place: its own test skips the error-code assertion on Windows because udp_socket.rs still reads the -1 as a getaddrinfo code, and node:dgram's connect() still throws a codeless error there. The fix for that is the udp_socket.rs and dgram.ts halves of this PR, which udp: resolve a hostname to the same address on the bind and connect side #38588 does not touch.
• The bsd.c hunk here is the ~10 lines that make the -1 contract explicit (capture the connect() error before freeaddrinfo(), define the empty-result case). It is not what makes the repro pass: with it stashed, the Windows debug build still reports EAFNOSUPPORT / EADDRNOTAVAIL for the cases in the tests, because freeaddrinfo happens to leave the Winsock error alone today. It is included so this PR does not depend on that, or on udp: resolve a hostname to the same address on the bind and connect side #38588 landing.
• Both PRs give the function the same contract, so whichever lands second drops its copy of that hunk; the rest of the two diffs do not overlap. Happy to drop the bsd.c hunk from this one instead if udp: resolve a hostname to the same address on the bind and connect side #38588 is expected to go in first.