fix: preserve h2 queue on out-of-order completion - #5410
Merged
Conversation
mcollina
requested review from
metcoder95 and
trivikr
and removed request for
metcoder95
June 10, 2026 13:13
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5410 +/- ##
==========================================
- Coverage 93.24% 93.23% -0.01%
==========================================
Files 110 110
Lines 36825 36842 +17
==========================================
+ Hits 34336 34351 +15
- Misses 2489 2491 +2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
mcollina
force-pushed
the
fix-h2-destroy-out-of-order-queue
branch
from
June 10, 2026 20:32
764c392 to
565bbd7
Compare
Signed-off-by: Matteo Collina <hello@matteocollina.com>
mcollina
force-pushed
the
fix-h2-destroy-out-of-order-queue
branch
from
June 11, 2026 07:53
565bbd7 to
04b4b68
Compare
metcoder95
approved these changes
Jun 11, 2026
Merged
mcollina
added a commit
that referenced
this pull request
Jul 30, 2026
…#5618) Backport of #5410 (and the fast path from #5569). HTTP/2 completes out of order, but every completion site advanced the running index blindly: client[kQueue][client[kRunningIdx]++] = null so whichever request happened to sit at the head was retired instead of the one that actually finished. With two streams in flight, completing the second one clears the first's slot while the second stays in the running window for good: after /second queue=[null, "/second"] runningIdx=1 pendingIdx=2 after /third queue=[null, null, "/third"] runningIdx=2 pendingIdx=3 The still-running /first is gone from the queue and two finished requests are counted as running forever, so kRunning never returns to zero. Since _resume() stops dispatching once kRunning reaches the concurrency limit, a client accumulating these eventually stops sending anything. Port completeRequest() from main: retire the request by identity, keeping the O(1) in-order fast path, and splice it out when it finished out of order. Cleared slots can now appear in the queue, so the paths that walk it skip them, as they do on main. Refs: #5404 Refs: #5410 Refs: #5569 Claude-Session: https://claude.ai/code/session_01A49JamgF2TkZHu5h58ChUM Signed-off-by: Matteo Collina <hello@matteocollina.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes: #5404
HTTP/2 streams can complete out of order. The H2 completion path was advancing
kRunningIdxand clearingkQueue[kRunningIdx], which assumes in-order completion. When a later stream completed first, this could clear the wrong request slot and leave completed/running entries misclassified. Destroy/error paths could then lose the still-running request or encounternullqueue entries.This changes H2 request finalization to remove the actual completed request from the running queue section, preserving other running requests. It also skips stale
nullentries defensively in destroy/error cleanup loops.Tested with:
node --test test/issue-5404.jsnode --test test/issue-5404.js test/http2-resume-null-request.js test/http2-goaway-retry-body.js test/http2-invalid-session.jsnode --test test/http2-dispatcher.jsnode --test test/issue-5404.js test/http2-pipelining-default.jsnpm run test:h2:corenpm run lint