`node:http2.createServer` fails for h2c (cleartext HTTP/2)

[kevgeoleo]

What version of Bun is running?

1.3.11-canary.1+9e93bfa1b

What platform is your computer?

Linux 5.10.0-12-amd64 x86_64 x86_64

What steps can reproduce the bug?

Hi,

I would like to report a behavior in Bun that can be reproduced by running the below snippet:

import http2 from "node:http2";

const server = http2.createServer((req, res) => {
  res.setHeader("Content-Type", "text/html");
  res.setHeader("X-Foo", "bar");
  res.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
  res.end("ok");
});

server.listen(8000);

What is the expected behavior?

root@KContainer:~/22618# fuser -k 8000/tcp || true && (node server.mjs &) && sleep 2 && curl --http2-prior-knowledge http://localhost:8000
8000/tcp:            27639
ok

What do you see instead?

http2.createServer() in Bun accepts a connection but returns an empty reply when using HTTP/2 prior knowledge (h2c), while the same code works correctly in Node.js

root@KContainer:~/22618fuser -k 8000/tcp || true && (bun run server.mjs &) && sleep 2 && curl --http2-prior-knowledge http://localhost:8000
8000/tcp:            27828
curl: (52) Empty reply from server

Additional information

No response

[robobun]

🟢 Round 4 review addressed — 9b14d91.

claude[bot] flagged that _final() calls callback() immediately after emit("wantTrailers"), which fires finish before an async wantTrailers listener has a chance to call sendTrailers().

While investigating I found a related latent bug that was also tripping a regression test I wrote: the StreamResponded bit was being set via stream[bunHTTP2StreamStatus] = status | StreamState.StreamResponded where status was captured BEFORE dispatching the stream/response event synchronously. A handler that mutates stream state in that window has its bits clobbered by the stale write-back.

• Fixed both server-side (line 2969) and client-side (line 3474) occurrences by switching to atomic |= and setting the bit BEFORE the emit.
• Deferred the full async-callback-stashing fix as a follow-up: making it work across the already-closed-by-native-end state machine needs more surgery than fits this PR's h2c-compatibility scope. The compat Http2ServerResponse layer is unaffected — onStreamTrailersReady calls sendTrailers synchronously, so the impact is limited to direct low-level users with async wantTrailers handlers.
• 5/5 regression tests still pass, existing test-http2-trailers.js still passes.

Threads: 7/7 resolved.

[robobun]

Fix is up in #29075 and verified end-to-end.

Status: PR is open and mergeable, 6/6 review threads resolved, real CI running on BuildKite build 44721 (commit 9d6522dbf4). The farm gate harness on my side cannot build from source in its container (TLS cert failures on github.com fetches for WebKit / tinycc / zig), so it keeps rejecting with BUILD FAILED instead of a test result. The fix itself works: on the debug binary in-container with the rebundled JS, all 5 regression tests pass; under USE_SYSTEM_BUN=1 (stock 1.3.11) 3/5 fail at the ENABLE_PUSH assertions, proving the bug.

Handing off to human review — BuildKite 44721 is the meaningful verification, not the farm gate.

[robobun]

(5th gate rejection, same environmental block.) PR #29075 is at 9b14d91c7d: 7/7 review threads resolved, 5/5 regression tests pass on the debug binary, Format/Lint/pipeline checks green, real CI build #44723 running the full matrix.

The local gate harness keeps failing to build from source in its container (unable to verify the first certificate on WebKit/tinycc/zig fetches from github.com). I cannot fix the container's TLS store from inside the repo, and the farm wipes any pre-populated cache between gate runs. Real CI on BuildKite's infrastructure is the meaningful verification here.

Stopping the rejection loop on my end. A human should decide whether to merge based on BuildKite #44723.