What the bug is

In Http2Stream.state (lines 2071-2078), after this PR the getter checks if (session) (truthy) but never checks session.destroyed. The session getter added in the same PR correctly returns undefined when session.destroyed === true. This creates a window where the two getters can return inconsistent values.

The specific code path that triggers it

ClientHttp2Session.#onError sets this[bunHTTP2Socket] = null (making session.destroyed === true) before calling this.destroy(error). Inside destroy(), parser.emitErrorToAllStreams() runs while this.#parser (bunHTTP2Native) is still non-null — it is only cleared on the line after emitErrorToAllStreams returns. The streamError handler runs synchronously during this call. During that synchronous window: stream.session returns undefined (new PR check fires because bunHTTP2Socket is null), but stream.state still returns live data because session is non-null (truthy) and session[bunHTTP2Native] is non-null.

Addressing the refutation

The refutation argues that ClientHttp2Session.#Handlers.streamError only does self.#connections-- then defers the actual error emission via process.nextTick(emitStreamErrorNT, ...), so by the time user code runs the inconsistent window is closed (both #parser and bunHTTP2Socket are null). This is a valid and specific technical point. If emitErrorToAllStreams() exclusively calls the internal streamError handler (which defers via nextTick), then user-registered 'error' listeners cannot observe the inconsistency, making this unobservable in practice.

Why it is still worth fixing

Even if the current execution path defers user callbacks via nextTick (making the gap unobservable today), the state getter's missing session.destroyed check is a defensive gap. If any future code path synchronously emits on stream objects during teardown, the inconsistency becomes observable immediately. More importantly, the PR itself treats session.destroyed as a meaningful signal for the session getter — omitting the same check from state is an incomplete implementation of the stated intent.

Step-by-step proof of the window

1. A client socket error fires ClientHttp2Session.#onError.
2. Line 3526: this[bunHTTP2Socket] = null — session.destroyed is now true.
3. Line 3532: this.destroy(error) is called.
4. Inside destroy(), line 3802: parser.emitErrorToAllStreams() runs; this.#parser is still non-null.
5. streamError handler fires synchronously: self.#connections--, then process.nextTick(emitStreamErrorNT, stream, error).
6. At this point (still inside step 5's synchronous frame): stream.session → session.destroyed === true → undefined; stream.state → session is truthy, session[bunHTTP2Native] is non-null → returns live {localWindowSize: N, ...}.
7. Line 3805: this.#parser = null. Only now would stream.state return {}.
8. process.nextTick fires emitStreamErrorNT; at this point both getters agree — but the inconsistency existed in the synchronous window of step 6.

The fix

In the state getter, change if (session) to if (session && \!session.destroyed):

get state() {
  const session = this[bunHTTP2Session];
  if (session && \!session.destroyed) {
    const native = session[bunHTTP2Native];
    if (native) return native.getStreamState(this.#id) ?? {};
  }
  return {};
}

What the bug is

At lines 7–8 of test/js/node/http2/h2-stream-after-destroy.test.ts, the test declares:

let resolveStream: (s: any) => void;
const streamP = new Promise<any>(r => (resolveStream = r));

This is the old-style escape-hatch pattern for turning a callback into a promise. test/CLAUDE.md line 106 explicitly forbids it: "When callbacks must be used and it's just a single callback, use Promise.withResolvers to create a promise that can be resolved or rejected from a callback."

The specific code path

The server.on('stream', s => { resolveStream(s); }) handler at lines 9–11 is exactly the single-callback case the CLAUDE.md rule targets. The recommended replacement is:

const { promise: streamP, resolve: resolveStream } = Promise.withResolvers<any>();

which eliminates the mutable let binding entirely.

Why existing code doesn't prevent it

There is no linter or compiler rule enforcing the CLAUDE.md convention; it is a style guideline enforced by code review only.

Impact

This is a purely stylistic issue — the test is functionally correct. The Promise constructor executes synchronously, so TypeScript (and the runtime) can guarantee resolveStream is assigned before the stream handler fires. No real TypeScript strict-mode error occurs here. However, the pattern is inconsistent with every other test in the test/js/node/http2/ directory: http2-helpers.cjs, node-http2-memory-leak.js, node-http2-upgrade.test.mts, and node-http2.test.js (15+ occurrences) all use Promise.withResolvers. This file is the sole outlier.

How to fix it

Replace lines 7–8:

// before
let resolveStream: (s: any) => void;
const streamP = new Promise<any>(r => (resolveStream = r));

// after
const { promise: streamP, resolve: resolveStream } = Promise.withResolvers<any>();

Step-by-step proof of the violation

1. Open test/CLAUDE.md line 106: rule is unambiguous — single-callback promise creation must use Promise.withResolvers.
2. Open h2-stream-after-destroy.test.ts lines 7–8: let resolveStream + new Promise(r => resolveStream = r) — exactly the pattern the rule disallows.
3. Compare to node-http2.test.js: const { promise, resolve } = Promise.withResolvers() used throughout — the project norm.
4. The resolveStream variable is used in the callback at line 11 (resolveStream(s)) — a single callback, matching the rule's scope exactly.
5. Conclusion: this is a CLAUDE.md style violation. No refutations were raised; all four verifiers confirmed it at nit severity.