[barathraj048]

When a compat API response finishes and the request had no body,
kMaybeDestroy() takes the graceful-close path and sends RST_STREAM(NO_ERROR)
right away. If the connection flow-control window is exhausted at that
point, the empty END_STREAM DATA frame is still queued, so the reset goes
out first and END_STREAM is dropped. The client gets the full body but no
END_STREAM, so it treats the response as incomplete.

This skips the graceful close when the request already ended with its
HEADERS frame, since there is no request body to stop.

This targets v26.x-staging because main is not affected: the trailer
changes in #64265 avoid this path, but the v26 backport (#64663) left
them out. I could also reproduce it on v22.16.0, and the issue reports
v24.x too.

Testing:

• Repro script from the issue: RST_STREAM(code=0) before the fix,
  DATA(0B, END_STREAM) after.
• Added test-http2-compat-serverresponse-end-stream-flow-control.js. It
  checks that /small gets END_STREAM before any reset, and that the server
  stream still closes on its own.
• python tools/test.py "parallel/test-http2-*": 283 passed (Windows x64).

Fixes: #66525
Refs: #64265
Refs: #64663

[nodejs-github-bot]

Review requested:

• @nodejs/http2
• @nodejs/net

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.74%. Comparing base (ca26282) to head (ec8c98c).
⚠️ Report is 1275 commits behind head on v26.x-staging.

Additional details and impacted files

@@                Coverage Diff                @@
##           v26.x-staging   #66672      +/-   ##
=================================================
+ Coverage          90.24%   90.74%   +0.49%     
=================================================
  Files                729      774      +45     
  Lines             242760   271784   +29024     
  Branches           46044    52069    +6025     
=================================================
+ Hits              219073   246619   +27546     
- Misses             15133    16065     +932     
- Partials            8554     9100     +546     

Files with missing lines	Coverage Δ
lib/internal/http2/core.js	95.38% <100.00%> (-0.15%)	⬇️

... and 400 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm

[github-actions]

Failed to start CI

   ℹ  Existing CI run found: https://ci.nodejs.org/job/node-test-pull-request/78335/
   ✖  Refusing to start a potentially duplicate CI job. Check the existing CI run in Jenkins and rebase the PR if needed. To start a new CI run manually: ncu-ci run https://github.com/nodejs/node/pull/66672

Full Auto Start CI output

�[36m⠋�[39m Getting reviews from nodejs/node/pull/66672
�[36m⠋�[39m Getting commits from nodejs/node/pull/66672
�[36m⠙�[39m Validating Jenkins credentials
�[36m⠙�[39m Validating Jenkins credentials
✔  Jenkins credentials valid
�[36m⠹�[39m Getting comments from nodejs/node/pull/66672
�[36m⠸�[39m Querying data for job/node-test-pull-request/78335/
�[36m⠸�[39m Querying data for job/node-test-pull-request/78335/
�[36m⠸�[39m Querying API for job/node-test-pull-request/78335/
✔  Build data downloaded
   ℹ  Existing CI run found: https://ci.nodejs.org/job/node-test-pull-request/78335/
   ✖  Refusing to start a potentially duplicate CI job. Check the existing CI run in Jenkins and rebase the PR if needed. To start a new CI run manually: ncu-ci run https://github.com/nodejs/node/pull/66672

View workflow run

[barathraj048]

The v26.x-staging branch was force-pushed after I opened this, and the
request-ci run failed because an earlier CI run (78335) already exists.
Should I rebase onto the current v26.x-staging before a new CI run, or is
it fine as-is? Happy to rebase if that helps.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/78480/

[barathraj048]

Thanks for the reviews and for starting CI. The only failure in 78480 is
node-test-commit-osx, but I don't have access to view the Jenkins logs.
Could someone check whether the failing test is related to this change?
If it's my new test, I'll look into making it more robust on macOS; if
it's an unrelated flake, could you resume CI? Thanks!

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/78683/