What the bug is and how it manifests

In emitClientStreamHeaders (lines 1919–1941), the code uses two separate if statements rather than a mutual if/else-if chain. When header_status === HTTP_STATUS_CONTINUE (100), the first if fires stream.emit('continue'). Then, because StreamResponded is never set for informational frames, the second outer if falls into its else branch, where header_status >= 100 && header_status < 200 is also true, so stream.emit('headers', headers, flags, rawheaders) fires too. Every HTTP 100 Continue response emits both 'continue' and 'headers'.

The specific code path that triggers it

The two guards are structurally independent if statements with no else link between them. When header_status === 100: (1) the first if matches HTTP_STATUS_CONTINUE and emits 'continue'; (2) the second if checks StreamResponded (not set for informational frames) and falls to else; (3) inside else, 100 >= 100 && 100 < 200 is true, so 'headers' is also emitted.

Node.js uses an if/else-if/else chain so once 'continue' is emitted the code returns; the 'headers' branch is never reached for status 100.

Why existing code does not prevent it

The StreamResponded flag is only set for final (>= 200) responses, so it provides no protection for informational frames. Nothing prevents both branches from executing in the same call for status 100.

What the impact would be

Any consumer listening to 'headers' to track informational responses (e.g., Early Hints handling, gRPC channel-level metadata) will receive a spurious 'headers' event for every upload that receives an Expect: 100-continue acknowledgement. This can corrupt state machines that expect 'headers' only for 101-199 informational responses, not for 100 Continue.

Step-by-step proof

1. Server sends HTTP/2 100 Continue in response to Expect: 100-continue.
2. Native parser calls streamHeaders -> emitClientStreamHeaders(self, stream, headers, flags, rawheaders).
3. header_status = headers[HTTP2_HEADER_STATUS] = 100.
4. header_status === HTTP_STATUS_CONTINUE -> true -> stream.emit('continue') fires.
5. (status & StreamState.StreamResponded) !== 0 -> false (100 is informational, flag not set) -> enter else.
6. header_status >= 100 && header_status < 200 -> true (100 satisfies both bounds) -> stream.emit('headers', ...) fires.
7. Both events emitted; Node.js only emits 'continue'.

How to fix it

Replace the two independent if statements with an else-if chain so the 'headers' branch is skipped when 'continue' was already emitted for status 100. This is pre-existing behavior: the original inline logic in streamHeaders had the same structural defect, and the PR faithfully extracted it into emitClientStreamHeaders without correcting it.

What the bug is and how it manifests

The PR correctly wraps three client-side native callbacks in kRequestAsyncResource.runInAsyncScope: streamData (via pushToStreamInScope), the end-of-stream push in the aborted/end block, and streamHeaders (via emitClientStreamHeaders). However, the three error-path handlers in ClientHttp2Session.#Handlers were not updated:

• frameError (~line 3341): calls process.nextTick(emitFrameErrorEventNT, stream, ...) with no async scope wrapping
• aborted (~line 3349): calls stream.emit('aborted') synchronously and process.nextTick(emitStreamErrorNT, ...) at ~line 3352, both without scope
• streamError (~line 3358): calls process.nextTick(emitStreamErrorNT, ...) without scope

The specific code path that triggers it

These are native-triggered callbacks that fire in the connect-time async context (the context active when http2.connect() was called). When they schedule work via process.nextTick, the microtask runs in whatever ambient context the event loop has at that point — not the per-request context captured by kRequestAsyncResource. The helper functions emitFrameErrorEventNT and emitStreamErrorNT are plain wrappers that simply call stream.emit with no scope restoration.

Why existing code doesn't prevent it

The runInAsyncScope pattern was only applied to the success path in this PR. The three error handlers share the same #Handlers object but were not touched. There is no automatic propagation of async scope via process.nextTick — each callback must explicitly call runInAsyncScope if it wants to restore context.

What the impact would be

Any application using AsyncLocalStorage for per-request context (trace IDs, tenant IDs, correlation IDs) that also handles errors on client streams will observe inconsistent behavior: storage.getStore() returns { id: 1 } (the per-request store) in 'response'/'data'/'end' handlers but returns { id: 0 } (the connect-time store) in 'error'/'frameError'/'aborted' handlers. This silent misbehavior can cause wrong trace spans, wrong tenant routing, or missed error attribution.

Step-by-step proof

1. User calls storage.run({ id: 0 }, () => http2.connect(...)) — connect-time store is { id: 0 }.
2. User calls storage.run({ id: 1 }, () => client.request(...)) — req[kRequestAsyncResource] captures { id: 1 }.
3. Server sends RST_STREAM or the connection drops; native fires the streamError handler.
4. streamError handler runs in the connect-time context (no scope wrapping) and calls process.nextTick(emitStreamErrorNT, stream, ...).
5. emitStreamErrorNT runs in the microtask queue's ambient context — also connect-time.
6. stream.emit('error', err) fires; user's handler calls storage.getStore() → receives { id: 0 }, not { id: 1 }.

How to fix it

Each error-path handler should retrieve stream[kRequestAsyncResource] and, if present, use it to wrap the process.nextTick call (or the synchronous emit) analogously to how streamHeaders was fixed:

frameError(self, stream, type, code) {
  const reqAsync = stream[kRequestAsyncResource];
  if (reqAsync) reqAsync.runInAsyncScope(process.nextTick, null, emitFrameErrorEventNT, stream, type, code);
  else process.nextTick(emitFrameErrorEventNT, stream, type, code);
},

The same pattern applies to the aborted and streamError handlers. This was pre-existing before the PR but the PR's stated goal of full ALS preservation makes the omission directly relevant.