[robobun]

Problem

The server.stop(false) drain promise resolved while keep-alive HTTP connections were still open and still serving.

// bun stopcensus.mjs [idle|inflight]
import net from "node:net";
const mode = process.argv[2] || "idle";
const server = Bun.serve({ port: 0, hostname: "127.0.0.1",
  async fetch(req) { const p = new URL(req.url).pathname; if (p === "/slow") await Bun.sleep(600); return new Response("resp:" + p + ";"); } });
const c = net.connect(server.port, "127.0.0.1");
// ... one GET, then await server.stop(false), then a second GET on the same socket

idle → stopResolvedAfterMs: 0, connFinAt: null, servedAfterResolve: 1; inflight → resolves at response-finish (~450 ms), connection open, /second served. Deterministic on 1.4.0.

Separately, server.stop(true) after an earlier server.stop(false) was a silent no-op: stop_from_js only entered stop() while has_listener(), and a prior graceful stop had already taken the listener.

Cause

deinit_if_we_can (and the get_all_closed_promise early-return, and the stop_listening unref gate) tested pending_requests == 0 && !has_listener() && !has_active_web_sockets(). Idle keep-alive HTTP connections are not in any of those terms; the predicate had no connection count, so it was satisfied while sockets were open and uWS kept routing requests on them.

Fix

• New active_connection_count: Cell<u32> on NewServer, fed by a uWS filter registered in listen() (fires +1 on accept / post-TLS-handshake, -1 from HttpContext::onClose). On WebSocket upgrade the socket is us_socket_adopt-ed out of the HTTP group and HttpContext::onClose never fires for it, so note_websocket_opened moves the count to the existing WebSocket tally.
• The drain predicate, the get_all_closed_promise early-return and the stop_listening unref gate now include !has_active_connections(). The early-return also gains !has_active_web_sockets(): after an upgrade the connection count is 0, so on a websocket-only server this term is what keeps a repeat stop() call from returning a fresh resolved promise while the stored one is still pending. stop(false) does not close existing connections (per the review on the previous revision of this PR); the promise waits for them to close via idleTimeout, client disconnect, server.closeIdleConnections() or server.stop(true).
• stop_from_js / dispose_from_js enter stop() for an abrupt stop whenever the app has not yet been terminated, and stop_listening performs the app.close() teardown in that state, so stop(true) after stop(false) force-closes the surviving connections.

Memory safety

The deferred js_value downgrade is also a use-after-free fix. On main, once pending_requests hits 0 after a graceful stop(), deinit_if_we_can downgrades the wrapper to Weak while surviving keep-alive connections can still dispatch. The wrapper's slots are the only GC root of the configured handlers, and JsRef::try_get() returns the raw JSValue of a Weak ref with no liveness check, so after a GC pass a late request on such a connection calls swept cells:

• release build: a freshly allocated object can reuse the swept handler cell and be invoked as the fetch handler. When the occupant is the fetch handler of another Bun.serve instance created after the stop, a request on the stopped server's surviving keep-alive connection is answered by that other instance's handler, crossing any in-process boundary between listeners (public vs admin, per-tenant servers). Other occupants surface as error: Expected a Response object, but received '6' (also '' / undefined), response bodies resolving to unrelated objects, or a segfault
• debug/ASAN build: UBSan Structure.h: member call on null pointer of type 'JSC::ClassInfo' in Bun__JSValue__call, reached from NewServer::on_request via us_internal_dispatch_ready_poll (a loop dispatch against the collected wrapper, not a finalizer-ordering problem)

With the connection count in the predicate, the wrapper stays Strong until the last connection is gone, so a late dispatch always sees live cells.

A standalone stress driver that creates fresh Bun.serve instances after every graceful stop confirms this: on unfixed builds it produces corrupted responses in release (about 1 per 120 stops over 72k rounds) and swept-cell sanitizer crashes under ASAN within 500 rounds, while this branch runs 1,000+ rounds under ASAN with zero reports.

Verification

New server.stop() drain promise counts open connections block in test/js/bun/http/bun-server.test.ts:

• idle keep-alive connection holds the promise until the client closes / in-flight request's connection holds the promise past response end: fail-before resolvedEarly: true, resolvedWhileOpen: true; after false, false and the promise resolves once the client destroys the socket.
• stop(true) after stop(false) force-closes the surviving connection: fail-before closed: false; after closed: true.

New request on a connection surviving graceful stop() never reaches a collected handler stress test: parks pooled keep-alive connections across stop(), drops the server binding, churns the heap and forces GC, then sends late requests on the surviving connections. Rounds alternate between a plain fetch handler and a routes: param-route server, because the route dispatch reads the wrapper's ServerRouteList cell, a second collected-cell site (UBSan member call on null TrailingArray<...ServerRouteList::IdentifierRange> in paramsObjectForRoute, reached from on_user_route_request). Fails consistently on main: 6/6 with the release build (wrong bodies, responses from an already-collected server, segfaults) and 9/9 with the debug ASAN build across both shapes of the test, hitting both UBSan sites. Passes repeatedly with this PR (~35 s under ASAN, ~8 s release).

The late keep-alive WebSocket upgrade after stop() test is updated: the wrapper downgrade is now deferred while the connection is open, so a pipelined upgrade on that connection reaches a live handler and server.upgrade() succeeds (previously it was refused because handler.server had been cleared).

bun bd test test/js/bun/http/bun-server.test.ts -t "drain promise counts open connections"  # 3 pass
USE_SYSTEM_BUN=1 bun test <same>                                                            # 3 fail

bun-server.test.ts, serve.test.ts, node-http.test.ts and websocket-server.test.ts are unchanged apart from the usual environment-only failures that also fail on main. node:http's server.close() calls closeIdleConnections() itself, so its observable behaviour is the same before and after.

The stop(true)-after-stop(false) gate overlaps #33662 and #34961; this PR carries it because the connection-count term makes it the only way to force the promise through when a client keeps the socket open.

---

no test proof · iteration 24 · Platform-specific test(s) that do not run on this machine. Deferring to CI, which covers all platforms: test/js/bun/http/bun-server.test.ts

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

Changes

Server shutdown now tracks active HTTP connections and delays deinitialization until connections drain. uWS filter callbacks now remain balanced across socket closure and WebSocket upgrades. Tests cover keep-alive, TLS, reload, pipelined request, and WebSocket behavior.

Server shutdown and connection accounting

Layer / File(s)	Summary
Connection filter accounting packages/bun-uws/src/*.h	Tracks filter-open state, preserves filter handlers across route resets, and balances filter-close callbacks during socket closure and WebSocket upgrades.
Active connection shutdown gating src/runtime/server/mod.rs	Counts active HTTP connections and uses the count in listener teardown, deinitialization, Node compatibility, and closed-promise conditions.
Shutdown control paths src/runtime/server/server_body.rs, src/runtime/server/mod.rs, test/harness.ts, test/vendor.json	Updates stop, dispose, idle-connection, termination, and test-harness shutdown paths.
Shutdown behavior validation test/js/bun/http/bun-server.test.ts	Adds coverage for graceful draining, force-close behavior, TLS accounting, reloads, late requests, WebSocket upgrades, and garbage collection.

Possibly related issues

• Bun.serve: server.stop() never resolves after a WebSocket is closed from the server side #36223: Addresses related HTTP and WebSocket connection accounting during graceful shutdown.

Possibly related PRs

• oven-sh/bun#35086: Addresses live connection counting and connection-drain behavior in another server implementation.
• oven-sh/bun#36097: Updates NewServer shutdown and resource cleanup paths.
• oven-sh/bun#36616: Extends graceful server.stop() handling with active HTTP connection tracking.

Suggested reviewers: jarred-sumner

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the primary change: graceful stop drain promises now wait for open connections.
Description check	✅ Passed	The description explains the problem, cause, fix, memory-safety impact, and verification results in substantial detail.

---

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

[robobun]

^{Updated 11:30 PM PT - Aug 4th, 2026}

❌ @robobun, your commit 4ca8102 has 2 failures in Build #89084 (All Failures):

• test/js/node/async_hooks/AsyncLocalStorage-tracking.test.ts - direct leak of 24b in run (src/runtime/node/node_crypto_binding.rs:85:21) +34 more on 🐧 13 x64-asan
• test/js/node/worker_threads/worker-transfer-terminate-stress.test.ts - SIGABRT on 🐧 13 x64-asan

---

🧪   To try this PR locally:

bunx bun-pr 35130

That installs a local version of the PR into your bun-35130 executable, so you can run:

bun-35130 --bun

[github-actions]

Found 2 issues this PR may fix:

1. Bun.serve server.stop() doesn't stop server when same port is reused/reuses handlers #6632 - Fixes server.stop() not closing idle keep-alive connections, which causes the port to appear still in use when rebinding
2. Unit testing Bun.serve.close() persists state between tests #12282 - Fixes graceful stop() leaving connections alive across test boundaries by now closing idle keep-alive connections immediately

If this is helpful, copy the block below into the PR description to auto-close these issues on merge.

Fixes #6632
Fixes #12282

🤖 Generated with Claude Code

[github-actions]

This PR may be a duplicate of:

1. Bun.serve: make stop(true) force-close after a prior graceful stop #33662 - Also fixes stop(true) being a no-op after stop(false) by modifying the same guard logic in stop_from_js/dispose_from_js and stop_listening
2. Bun.serve: end open WebSockets with 1001 on server.stop() #34961 - Includes the same stop(true)-after-stop(false) fix and modifies the same server files, with overlapping connection teardown logic

🤖 Generated with Claude Code

[claude]

Additional findings (outside current diff — PR may have been updated during review):

• 🔴 src/runtime/server/mod.rs:1652-1664 — The js_value_for_new_request() 503 gate is only wired into the dynamic-handler trampolines; StaticRoute::on/on_head, FileRoute::on_request, html_bundle::Route::on_request, and trampoline::on_404 have no has_listener() check, so a keep-alive socket that survived stop(false) (in-flight at stop time) can pipeline requests to a static route indefinitely with idleTimeout: 0. Since b2f9c2c dropped the deinit_if_we_can idle sweep and made this gate the sole close mechanism, the comment here ("Any request that races this on a surviving socket is answered 503") is false for those siblings — either add the gate to each (they all reach the server via (*this).server.get() / userdata) or restore a post-drain sweep.

  Extended reasoning...

  What the bug is

  This PR's fix has two mechanisms for closing keep-alive connections after a graceful stop(false):

  1. close_idle_connections() in stop_listening — closes sockets that are idle at stop time.
  2. The new js_value_for_new_request() gate in the dispatch trampolines — refuses (503 + Connection: close) any request that arrives on a socket that was non-idle at stop time and therefore survived (1).

  Commit b2f9c2c removed the third mechanism (the deinit_if_we_can idle sweep) with the stated rationale: "The per-request 503 + Connection: close already closes a surviving keep-alive on its next request." The comment at mod.rs:1654-1656 restates this: "Any request that races this on a surviving socket is answered 503 by the js_value_for_new_request gate."

  But the 503 gate is only applied to the dynamic-handler trampolines (on_request, on_user_route_request, on_request_for, on_user_route_request_for, upgrade_web_socket_user_route, and the Bun.serve arm of on_websocket_upgrade_request). The following sibling trampolines — all registered directly with uWS via apply_static_route / set_routes — dispatch new requests on the same keep-alive socket with no has_listener() / js_value_for_new_request() check:

  • StaticRoute::on (StaticRoute.rs:351) and StaticRoute::on_head (StaticRoute.rs:284) — call server.on_pending_request() and serve the blob unconditionally, ending with resp.should_close_connection() (which only reflects the request's Connection header, not listener state).
  • FileRoute::on_request (FileRoute.rs:303) — same shape.
  • html_bundle::Route::on_request — same shape.
  • trampoline::on_404 (mod.rs:3178) — resp.end(b"", false), i.e. keep-alive.

  Step-by-step proof

  Bun.serve({
    port: 0, idleTimeout: 0,
    routes: { "/s": new Response("static") },
    async fetch() { inflight.resolve(); await release.promise; return new Response("ok"); },
  });

  1. Client opens a TCP connection, sends GET / HTTP/1.1 → on_request → handler parks on release. Connection is non-idle (pending_requests == 1).
  2. server.stop(false): listener.take() succeeds; close_idle_connections() runs but skips this socket (uWS marks it non-idle while a response is outstanding).
  3. release.resolve() → handler returns → 200 keep-alive → on_request_complete → deinit_if_we_can. Since b2f9c2c, deinit_if_we_can contains no close_idle_connections() call and pending_requests == 0 alone does not close the socket. The socket is now idle and open.
  4. Client pipelines GET /s HTTP/1.1 on the same socket → uWS routes to StaticRoute::on_request → StaticRoute::on. No has_listener() check. server.on_pending_request() bumps the count, the blob is written, resp.should_close_connection() returns false (client did not send Connection: close), response ends keep-alive.
  5. on_static_request_complete → deinit_if_we_can (again no sweep). Socket stays open.
  6. Repeat step 4 forever. The fd is never released and the "stopped" server keeps serving /s.

  The PR's own third test (graceful stop() closes a connection once its in-flight request completes) demonstrates step 3 reaches a trampoline (it observes ["200","503"]); changing the pipelined GET /after to hit the static route would yield ["200","200"] with closed: false instead.

  Why existing code doesn't prevent it

  • resp.should_close_connection() only reads uWS's HTTP_CONNECTION_CLOSE state (client's Connection: close or HTTP/1.0), never the server's listener state.
  • deinit_if_we_can (mod.rs:1707+) no longer sweeps — the block that called close_idle_connections() on !has_listener() && !TERMINATED was deleted in b2f9c2c.
  • StaticRoute::on reaches the server via (*this).server.get() but never consults has_listener(); on_404 ignores its user_data entirely.

  Impact

  This is the exact bug class the PR is fixing (a stopped server keeps serving and holds fds forever with idleTimeout: 0), left open on a common configuration — routes: { "/": new Response(...) } is the documented static-route form. The rationale for b2f9c2c ("the 503 gate already closes a surviving keep-alive on its next request") is invalid for these paths, and the in-code comment at 1654-1656 now overstates the guarantee. REVIEW.md: "Fix the whole class in the same PR — grep for every sibling site sharing the pattern." Bounded by the in-flight count at stop() time and recoverable via stop(true), but with idleTimeout: 0 a client that keeps pipelining to a static route holds a "stopped" server open indefinitely.

  How to fix

  Either:

  • Add the has_listener() gate to each sibling trampoline. StaticRoute::on/on_head and FileRoute::on already have (*this).server.get(); check !server.has_listener() and call respond_stopped_503(resp) (or end with close_connection = true) before serving. on_404 receives the server as user_data — cast and check the same way. This mirrors the gate the PR added to on_request/on_user_route_request.
  • Or restore a targeted idle sweep (e.g. one close_idle_connections() when pending_requests first reaches 0 on a gracefully-stopped Bun.serve server), if the Windows race that motivated b2f9c2c can be avoided by deferring the sweep past the flush.

  The PR description's Fix bullet ("deinit_if_we_can sweeps idle connections whenever it runs on a gracefully-stopped Bun.serve server") also needs updating — that sweep was removed in b2f9c2c.

[robobun]

Addressed the sibling-trampoline gap in 3413389: StaticRoute::on_request/on_head_request, FileRoute::on, html_bundle::Route::on_any_request, and trampoline::on_404 now check AnyServer::has_listener() and answer 503 + Connection: close once the listener is gone. Verified with a repro that pipelines GET /s (static route) behind an in-flight request across stop(false): before ["200","200","200"], closed:false; after ["200","503","503"], closed:true. The in-flight-at-stop test in bun-server.test.ts now also pipelines at a static route. PR body updated to drop the stale deinit_if_we_can sweep mention.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/runtime/server/StaticRoute.rs`:
- Around line 262-277: Consolidate the duplicated stopped-server check into a
shared pub(super) refuse_if_stopped helper beside respond_stopped_503_any in
src/runtime/server/server_body.rs, accepting Option<AnyServer> and AnyResponse
and returning whether it responded. In
src/runtime/server/StaticRoute.rs:262-277, replace the local helper logic with a
call passing (*this).server.get(); in src/runtime/server/FileRoute.rs:331-336,
replace the inline check with the shared helper; and in
src/runtime/server/HTMLBundle.rs:271-275, preserve the existing None handling
and route the listener check through the shared helper.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 3d477c48-2200-40fb-83b9-2b83c2a0c96f

📥 Commits

Reviewing files that changed from the base of the PR and between 47597ab and cc765e4.

📒 Files selected for processing (7)

• src/runtime/server/FileRoute.rs
• src/runtime/server/HTMLBundle.rs
• src/runtime/server/StaticRoute.rs
• src/runtime/server/mod.rs
• src/runtime/server/server_body.rs
• test/js/bun/http/bun-server.test.ts
• test/vendor.json

[claude]

No bugs found this pass; the earlier rounds of feedback (sibling-trampoline gates, DEBUG diagnostic routes, on_404 test coverage, shared refuse_if_stopped_any helper) are all addressed in the latest commits. Deferring to a human because this is a user-facing semantic change to Bun.serve's stop() — it now closes idle keep-alive sockets and 503s post-stop requests, which the added test/vendor.json skip notes breaks an elysia test that asserted the old behaviour, and the PR overlaps #33662 / #34961 on the stop(true)-after-stop(false) gate.

What was reviewed:

• stop_listening abrupt-after-graceful block: unref/TERMINATED ordering, deinit_running re-entrancy guard in stop_from_js, and that the pre-call already_terminated capture keeps the TCP app.close() from being masked on SSL+http3. (The H3-side escalation gap flagged earlier was left as-is; already noted, not repeating.)
• Every trampoline registered in set_routes now routes through has_listener() (StaticRoute/FileRoute/HTMLBundle via refuse_if_stopped_any, on_404, on_bun_info_request, on_chrome_devtools_json_request, upgrade, H3 siblings); node:http dispatch intentionally keeps the finalize-only gate.
• refuse_if_stopped_any placement: called before ref_()/on_pending_request() in each route so no ref/pending-count leaks on the 503 path; None server left to caller as documented.
• New tests: setup errors reject the awaited promise, subprocess pipes drained concurrently, bounded polling instead of fixed sleeps, and the routes-only fixture now makes the on_404 gate load-bearing.

Extended reasoning...

Overview

The PR changes Bun.serve's graceful stop() to (1) close idle keep-alive connections via close_idle_connections(), (2) refuse post-stop requests on surviving sockets with 503 + Connection: close at every request trampoline, and (3) let stop(true) after stop(false) actually escalate to a force-close instead of no-opping. It touches src/runtime/server/{mod,server_body,StaticRoute,FileRoute,HTMLBundle}.rs, adds ~230 lines of tests to bun-server.test.ts, updates two existing tests to expect 503 instead of 200, and adds a vendor-test skip for elysia's core*stop.test.ts.

Security risks

None identified. The change tightens behaviour (a stopped server refuses more, not less). The 503 gate on the DEBUG-only diagnostic routes (/bun:info, chrome-devtools JSON) is a hardening, and refuse_if_stopped_any runs before any ref-count bump or on_pending_request() so the refusal path cannot leak.

Level of scrutiny

High — this is the Bun.serve lifecycle/teardown state machine. It changes what stop(false) means for existing keep-alive clients (previously they kept being served; now they're closed/503'd), which is a deliberate semantic shift the elysia vendor test was asserting against. The stop_listening change adds a new state (listener-already-taken + abrupt) with its own unref/TERMINATED/app.close() sequencing, and stop_from_js/dispose_from_js gain a re-entrancy guard on deinit_running. That's exactly the kind of ref-count / event-loop-ref / connection-lifecycle interaction a maintainer should sign off on.

Other factors

• API-semantics decision: the PR body argues the old behaviour was a bug (fd leak, stopped server keeps serving), and the linked #6632 supports that. But the elysia skip shows at least one downstream framework encoded the old semantics in a test; a maintainer should confirm this is the intended contract for stop(false).
• PR overlap: the description says this overlaps #33662 and #34961 on the abrupt-after-graceful gate; a human should coordinate which lands.
• Prior review rounds: three rounds of my inline findings (sibling trampolines, DEBUG routes, on_404 coverage, unref-claim in test comment) were each addressed in follow-up commits (6a82c47, 3413389, cc765e4, 3b0a53d, f3226d1). The remaining H3 abrupt-after-graceful gap I flagged at 14:07 was resolved without a code change — low-impact and already on record, not re-raising.
• Test quality: the new tests spawn subprocesses with bunEnv, drain stdout/stderr/exited concurrently, poll with a deadline rather than fixed sleeps, and assert combined {stderr, out, exitCode} objects. The routes-only fixture in the pipelined-503 test now actually reaches on_404 (per f3226d1).

Given the semantic change, the server-lifecycle state-machine edits, and the cross-PR overlap, this warrants a human look even with no bugs found.

[robobun]

CI at f3226d1 (build #77903): 191/196 jobs passed. The two red tests are test/js/node/test/parallel/test-net-connect-memleak.js and test/js/node/test/parallel/test-gc-http-client-connaborted.js, both GC-timing Node parallel tests that also fail on main (build #77601) and pass locally with this build; neither touches code this PR changes. Everything this PR touches (bun-server.test.ts, serve.test.ts, bun-serve-static/file/routes, websocket-server, node-http, the elysia vendor suite, both Windows lanes) is green.

[Jarred-Sumner]

Can we move this check to the very start of a request handler before we allocate? Instead of allocating and then checking. We could even move this to uWS with a flag on the App itself.

[robobun]

Moved into uWS in cb06df6: a new draining bit on HttpContextData::flags, set by TemplatedApp::startDraining() (which also runs closeIdle()). The check now sits in HttpContext's request-handler lambda right before selectedRouter->route(), so every H1 route (dynamic, static, file, html-bundle, 404, diagnostic, WebSocket upgrade) is refused with 503 + Connection: close in one place before any Rust trampoline or RequestContext allocation runs.

stop_listening(false) calls app.start_draining() for Bun.serve servers (skipped for node:http, whose close() keeps non-idle sockets serviceable per Node semantics). All the per-trampoline has_listener() gates, js_value_for_new_request, refuse_if_stopped_any, and AnyServer::has_listener() are gone; the Rust-side diff is back down to stop_listening/stop_from_js/dispose_from_js only. Same four tests in bun-server.test.ts still fail-before / pass-after.

[Jarred-Sumner]

Note that stop() / stop(false) should be graceful; by design it should not be closing existing connections

[robobun]

Understood. To make sure I scope this correctly, which of these do you want stop(false) to do?

1. Keep serving on existing connections (current behaviour on main): listener closes, idle keep-alives stay open and keep dispatching new requests until the idle timeout (or forever with idleTimeout: 0). The promise resolves once pending_requests reaches 0 regardless of open idle sockets.
2. Keep the connections open but stop dispatching (this PR at cb06df6): listener closes, idle keep-alives are closed, surviving sockets get 503 + Connection: close on their next request.
3. Keep in-flight requests, close idle only (Node's server.close()): listener closes, idle keep-alives are closed now, non-idle sockets keep being served until their in-flight response completes.

If (1) is the intended graceful semantics, then the bug from the original report is just the stop(true)-after-stop(false) no-op (plus maybe the promise resolving before the app is actually drained), and I should drop the startDraining() / 503 changes here and keep only the escalation fix. The elysia test skip and the "refuses new requests" test would go too.

Happy to narrow it down; just want to pick the right contract before I rework it.

[claude]

Beyond the two inline nits, on the cb06df6 architecture I checked that the uWS draining gate is inert for node:http (start_draining() is gated on on_node_http_request.is_empty(), so the flag stays false and the HttpContext.h check never fires there), and that endWithoutBody(std::nullopt, true) sets HTTP_CONNECTION_CLOSE so the post-parse shouldCloseConnection() path shuts the socket down after the 503 run flushes. Deferring — this changes stop() semantics (breaks elysia's stop test), touches vendored uWS, and overlaps #33662/#34961; a maintainer should sign off.

Extended reasoning...

The final commit moved the 503 gate into uWS as a per-context draining bit checked in the request-handler lambda before routing, replacing the per-trampoline Rust gates my earlier reviews covered. Since I hadn't reviewed that architecture, I verified the two obvious cross-cutting concerns: node:http shares HttpContext<SSL> but never has draining set (the Rust caller gates on on_node_http_request.is_empty()), and the 503's closeConnection=true reaches internalEnd → HTTP_CONNECTION_CLOSE → the post-consumePostPadded shutdown check, so the socket does close after the pipelined 503s are written. The two nits this run are test-prose/assertion-strength only. Not approving because this is a user-visible behaviour change to Bun.serve().stop() (the elysia vendor-test skip documents that), it modifies vendored uWS lifecycle code, and it overlaps two other open PRs on the stop(true)-after-stop(false) gate — those are maintainer calls.

[robobun]

Reworked per the review ("stop(false) should be graceful; by design it should not be closing existing connections"): dropped the uWS draining gate and the idle-connection close. The fix is now purely on the drain-promise side: NewServer tracks an open-HTTP-connection count via a uWS filter, and the drain predicate includes it alongside pending_requests and the WebSocket count. stop(false) leaves existing connections alone; the promise resolves once they close (idleTimeout / client disconnect / closeIdleConnections() / stop(true)). Kept the stop(true)-after-stop(false) escalation so a caller has a way to force the drain through. Force-pushed from main at 0a1c51f.

[robobun]

The stop-keepalive churn test added here was flaking on darwin CI with foreign-listener responses (a macOS ephemeral-allocator quirk lets a wildcard port-0 bind land on a port a leaked process holds at 127.0.0.1). Fixed by binding loopback in #37141.