quic: write desired size needs update on maxstream

[martenrichter]

Without this update the streams can stall, if the chunks are close or bigger than the window size.
It was provoked by a very special timing, so probably hard to test,
Though I do not know, if this is also required for max data of the whole session.
Upstream says no:
ngtcp2/ngtcp2#2243

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[martenrichter]

@jasnell@pimterry can you have a look?

[avivkeller]

Can you add a test?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.14%. Comparing base (9024119) to head (ad505ca).
⚠️ Report is 411 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #64768 +/- ##
==========================================
- Coverage 90.15% 90.14% -0.01% 
==========================================
Files 743 746 +3 Lines 242407 242660 +253 Branches 45645 45723 +78 ==========================================
+ Hits 218532 218750 +218 - Misses 15357 15425 +68 + Partials 8518 8485 -33 

see 55 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.

[martenrichter]

Can you add a test?

Not really. I found it in my webtransport test suite. But there it happens only, if I use node.js server and client. If I choose a Quiche client and a Node.js server, or a Node.js client and a Quiche server, it does not surface, as it depends on the particular packet size the particular Quic internals are generating at the low level. But I will later port all of my wt tests over, but therefore wt must be ready. (But this must not mean that these would reliably trigger the issue).

[pimterry]

Not really. I found it in my webtransport test suite.

I wanted to understand, so I did some digging. I think the trigger is actually quite clear: UpdateWriteDesiredSize was only called on ack, but the stream window is extended independently of acks. A peer can ack all our data, wait (all data acked but zero window available) and then extend the window size to allow more data later - so we do need to update desired size based on the window update alone 👍. Good find @martenrichter! This is tricky to trigger as it's easily obscured by buffering.

We can repro it reliably with something like this:

import{createPrivateKey}from'node:crypto';import{readFile}from'node:fs/promises';import{setTimeoutassleep}from'node:timers/promises';import{listen,connect}from'node:quic';import{drainableProtocol}from'stream/iter';constkeys='test/fixtures/keys';constkey=createPrivateKey(awaitreadFile(`${keys}/agent1-key.pem`));constcert=awaitreadFile(`${keys}/agent1-cert.pem`);constWINDOW=4096;// Fills the window exactly: HTTP/3 spends 11 of those bytes on framing (8 for// the HEADERS frame below, 3 for the DATA frame header). The send buffer then// empties at the same moment the window reaches zero, leaving nothing in// flight to ack. Any other size leaves bytes queued, and the ack for those// wakes the writer instead, hiding the bug.constBODY=WINDOW-11;letletServerRead;constserverMayRead=newPromise((resolve)=>{letServerRead=resolve;});constendpoint=awaitlisten((session)=>{session.onstream=async(stream)=>{awaitserverMayRead;forawait(const_ofstream){/* reading extends the window */}};},{sni: {'*': {keys: [key],certs: [cert]}},transportParams: {initialMaxStreamDataBidiRemote: WINDOW,initialMaxData: 1024*1024,},onheaders(){this.sendHeaders({':status': '200'});},});constsession=awaitconnect(endpoint.address,{servername: 'localhost',verifyPeer: 'manual',});awaitsession.opened;// Budget well above the window, so the window is what stops the writer.conststream=awaitsession.createBidirectionalStream({budget: 1024*1024});stream.sendHeaders({':method': 'POST',':path': '/',':scheme': 'https',':authority': 'localhost',},{terminal: false});constwriter=stream.writer;writer.writeSync(newUint8Array(BODY));// Long enough for every byte to be acked. The peer acks as data arrives,// whether or not its application has read any of it, so by now the window is// exhausted, the send buffer is empty, and no further ACK can arrive.awaitsleep(500);console.log('all acked, window exhausted');constwatchdog=setTimeout(()=>{console.log('STALLED: no drain after MAX_STREAM_DATA');process.exit(1);},5000);letServerRead();// extend the window, with no ack attachedconsole.log('window extended');awaitwriter[drainableProtocol]();console.log('writer drain');clearTimeout(watchdog);console.log('done');process.exit(0);

This creates a server which doesn't read, so it'll ack everything without extending the window. The client writes the exact amount to fill the window but leave nothing in its buffers (otherwise the window update triggers more writes, and then gets acks). Then after a 500ms pause, the server reads and triggers a window update.

Fixed client will trigger a drain and complete OK, bad client will stall forever. We should be able to build a test around that directly.

The fix here covers this for HTTP/3, but doesn't totally fix the issue because we have two independent implementations of this with the current application structure, so we'll need to also separately fix the equivalent issue again for pure QUIC in the default app.

[martenrichter]

And we may also need it for session window, but I think we also need a callback from ngtcp2 for this.
Btw. that is the reason why there was so little progress from the last 3 weekends, it was horrible to debug (and I had a second error in the client code that was interfering).

[martenrichter]

@pimterry I am tring to integrate your test. But actually, the bug I was catching was different; it was actually two buffers, one inside the window size and the other going beyond the window size. At least this what I remember from debugging.

[martenrichter]

Ok, also done for pure quic.
What is missing though, is the same for maxdata.
So I think we should create a separate issue for this with test, but I do not see a fix, as the ngtcp2 callback is missing.
I am refering to this line:

node/src/quic/streams.cc

Line 1873 in 41525ab

uint64_t conn_left = ngtcp2_conn_get_max_data_left(conn);

it is less likely to cause a stall, but it may happen.

[martenrichter]

Create a separate issue for maxdata, as I have no clue how to address it currently.
#64835

[nodejs-github-bot]

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

[trivikr]

It looks like this PR is ready to land.

[nodejs-github-bot]

Commit Queue failed

- Loading data for nodejs/node/pull/64768
✔ Done loading data for nodejs/node/pull/64768
----------------------------------- PR info ------------------------------------
Title quic: write desired size needs update on maxstream (#64768)
⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!
Branch martenrichter:writedesired -> nodejs:main
Labels c++, needs-ci, quic, commit-queue, commit-queue-squash
Commits 10
- quic: write desired size needs update on maxstream
- quic: Fix lint
- quic: add test for maxstreamdata buffer stalls
- quic: rename test
- quic: fix streamaxdata for non http/3
- quic: Fix lint
- quic: fix lint
- Fix lint2
- Fix lint 3
- Fix lint 4
Committers 2
- Marten Richter <marten.richter@tu-berlin.de>
- Marten Richter <marten.richter@freenet.de>
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
------------------------------ Generated metadata ------------------------------
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
--------------------------------------------------------------------------------
ℹ This PR was created on Sun, 26 Jul 2026 20:26:23 GMT
✔ Approvals: 1
✔ - James M Snell (@jasnell) (TSC): https://github.com/nodejs/node/pull/64768#pullrequestreview-4889028017
✘ GitHub CI is still running
ℹ Last Full PR CI on 2026-08-20T03:22:16Z: https://ci.nodejs.org/job/node-test-pull-request/76030/
- Querying data for job/node-test-pull-request/76030/
✔ Build data downloaded
✔ Last Jenkins CI successful
--------------------------------------------------------------------------------
✔ Aborted `git node land` session in /home/runner/work/node/node/.ncu

https://github.com/nodejs/node/actions/runs/32384310354

[martenrichter]

It says: "⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!"
I wonder what this means. PR worked before for me with node.js .

[jasnell]

I wouldn't worry about that. I'll squash and merge these directly.

[jasnell]

Landed in 2bfc1e9

[martenrichter]

Without this update the streams can stall, if the chunks are close or bigger than the window size.
It was provoked by a very special timing, so probably hard to test,
Though I do not know, if this is also required for max data of the whole session.
Upstream says no:
ngtcp2/ngtcp2#2243

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[martenrichter]

@jasnell@pimterry can you have a look?

[avivkeller]

Can you add a test?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.14%. Comparing base (9024119) to head (ad505ca).
⚠️ Report is 411 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #64768 +/- ##
==========================================
- Coverage 90.15% 90.14% -0.01% 
==========================================
Files 743 746 +3 Lines 242407 242660 +253 Branches 45645 45723 +78 ==========================================
+ Hits 218532 218750 +218 - Misses 15357 15425 +68 + Partials 8518 8485 -33 

see 55 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.

[martenrichter]

Can you add a test?

Not really. I found it in my webtransport test suite. But there it happens only, if I use node.js server and client. If I choose a Quiche client and a Node.js server, or a Node.js client and a Quiche server, it does not surface, as it depends on the particular packet size the particular Quic internals are generating at the low level. But I will later port all of my wt tests over, but therefore wt must be ready. (But this must not mean that these would reliably trigger the issue).

[pimterry]

Not really. I found it in my webtransport test suite.

I wanted to understand, so I did some digging. I think the trigger is actually quite clear: UpdateWriteDesiredSize was only called on ack, but the stream window is extended independently of acks. A peer can ack all our data, wait (all data acked but zero window available) and then extend the window size to allow more data later - so we do need to update desired size based on the window update alone 👍. Good find @martenrichter! This is tricky to trigger as it's easily obscured by buffering.

We can repro it reliably with something like this:

import{createPrivateKey}from'node:crypto';import{readFile}from'node:fs/promises';import{setTimeoutassleep}from'node:timers/promises';import{listen,connect}from'node:quic';import{drainableProtocol}from'stream/iter';constkeys='test/fixtures/keys';constkey=createPrivateKey(awaitreadFile(`${keys}/agent1-key.pem`));constcert=awaitreadFile(`${keys}/agent1-cert.pem`);constWINDOW=4096;// Fills the window exactly: HTTP/3 spends 11 of those bytes on framing (8 for// the HEADERS frame below, 3 for the DATA frame header). The send buffer then// empties at the same moment the window reaches zero, leaving nothing in// flight to ack. Any other size leaves bytes queued, and the ack for those// wakes the writer instead, hiding the bug.constBODY=WINDOW-11;letletServerRead;constserverMayRead=newPromise((resolve)=>{letServerRead=resolve;});constendpoint=awaitlisten((session)=>{session.onstream=async(stream)=>{awaitserverMayRead;forawait(const_ofstream){/* reading extends the window */}};},{sni: {'*': {keys: [key],certs: [cert]}},transportParams: {initialMaxStreamDataBidiRemote: WINDOW,initialMaxData: 1024*1024,},onheaders(){this.sendHeaders({':status': '200'});},});constsession=awaitconnect(endpoint.address,{servername: 'localhost',verifyPeer: 'manual',});awaitsession.opened;// Budget well above the window, so the window is what stops the writer.conststream=awaitsession.createBidirectionalStream({budget: 1024*1024});stream.sendHeaders({':method': 'POST',':path': '/',':scheme': 'https',':authority': 'localhost',},{terminal: false});constwriter=stream.writer;writer.writeSync(newUint8Array(BODY));// Long enough for every byte to be acked. The peer acks as data arrives,// whether or not its application has read any of it, so by now the window is// exhausted, the send buffer is empty, and no further ACK can arrive.awaitsleep(500);console.log('all acked, window exhausted');constwatchdog=setTimeout(()=>{console.log('STALLED: no drain after MAX_STREAM_DATA');process.exit(1);},5000);letServerRead();// extend the window, with no ack attachedconsole.log('window extended');awaitwriter[drainableProtocol]();console.log('writer drain');clearTimeout(watchdog);console.log('done');process.exit(0);

This creates a server which doesn't read, so it'll ack everything without extending the window. The client writes the exact amount to fill the window but leave nothing in its buffers (otherwise the window update triggers more writes, and then gets acks). Then after a 500ms pause, the server reads and triggers a window update.

Fixed client will trigger a drain and complete OK, bad client will stall forever. We should be able to build a test around that directly.

The fix here covers this for HTTP/3, but doesn't totally fix the issue because we have two independent implementations of this with the current application structure, so we'll need to also separately fix the equivalent issue again for pure QUIC in the default app.

[martenrichter]

And we may also need it for session window, but I think we also need a callback from ngtcp2 for this.
Btw. that is the reason why there was so little progress from the last 3 weekends, it was horrible to debug (and I had a second error in the client code that was interfering).

[martenrichter]

@pimterry I am tring to integrate your test. But actually, the bug I was catching was different; it was actually two buffers, one inside the window size and the other going beyond the window size. At least this what I remember from debugging.

[martenrichter]

Ok, also done for pure quic.
What is missing though, is the same for maxdata.
So I think we should create a separate issue for this with test, but I do not see a fix, as the ngtcp2 callback is missing.
I am refering to this line:

node/src/quic/streams.cc

Line 1873 in 41525ab

uint64_t conn_left = ngtcp2_conn_get_max_data_left(conn);

it is less likely to cause a stall, but it may happen.

[martenrichter]

Create a separate issue for maxdata, as I have no clue how to address it currently.
#64835

[nodejs-github-bot]

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

[trivikr]

It looks like this PR is ready to land.

[nodejs-github-bot]

Commit Queue failed

- Loading data for nodejs/node/pull/64768
✔ Done loading data for nodejs/node/pull/64768
----------------------------------- PR info ------------------------------------
Title quic: write desired size needs update on maxstream (#64768)
⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!
Branch martenrichter:writedesired -> nodejs:main
Labels c++, needs-ci, quic, commit-queue, commit-queue-squash
Commits 10
- quic: write desired size needs update on maxstream
- quic: Fix lint
- quic: add test for maxstreamdata buffer stalls
- quic: rename test
- quic: fix streamaxdata for non http/3
- quic: Fix lint
- quic: fix lint
- Fix lint2
- Fix lint 3
- Fix lint 4
Committers 2
- Marten Richter <marten.richter@tu-berlin.de>
- Marten Richter <marten.richter@freenet.de>
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
------------------------------ Generated metadata ------------------------------
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
--------------------------------------------------------------------------------
ℹ This PR was created on Sun, 26 Jul 2026 20:26:23 GMT
✔ Approvals: 1
✔ - James M Snell (@jasnell) (TSC): https://github.com/nodejs/node/pull/64768#pullrequestreview-4889028017
✘ GitHub CI is still running
ℹ Last Full PR CI on 2026-08-20T03:22:16Z: https://ci.nodejs.org/job/node-test-pull-request/76030/
- Querying data for job/node-test-pull-request/76030/
✔ Build data downloaded
✔ Last Jenkins CI successful
--------------------------------------------------------------------------------
✔ Aborted `git node land` session in /home/runner/work/node/node/.ncu

https://github.com/nodejs/node/actions/runs/32384310354

[martenrichter]

It says: "⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!"
I wonder what this means. PR worked before for me with node.js .

[jasnell]

I wouldn't worry about that. I'll squash and merge these directly.

[jasnell]

Landed in 2bfc1e9

[martenrichter]

Without this update the streams can stall, if the chunks are close or bigger than the window size.
It was provoked by a very special timing, so probably hard to test,
Though I do not know, if this is also required for max data of the whole session.
Upstream says no:
ngtcp2/ngtcp2#2243

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[martenrichter]

@jasnell@pimterry can you have a look?

[avivkeller]

Can you add a test?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.14%. Comparing base (9024119) to head (ad505ca).
⚠️ Report is 411 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #64768 +/- ##
==========================================
- Coverage 90.15% 90.14% -0.01% 
==========================================
Files 743 746 +3 Lines 242407 242660 +253 Branches 45645 45723 +78 ==========================================
+ Hits 218532 218750 +218 - Misses 15357 15425 +68 + Partials 8518 8485 -33 

see 55 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.

[martenrichter]

Can you add a test?

Not really. I found it in my webtransport test suite. But there it happens only, if I use node.js server and client. If I choose a Quiche client and a Node.js server, or a Node.js client and a Quiche server, it does not surface, as it depends on the particular packet size the particular Quic internals are generating at the low level. But I will later port all of my wt tests over, but therefore wt must be ready. (But this must not mean that these would reliably trigger the issue).

[pimterry]

Not really. I found it in my webtransport test suite.

I wanted to understand, so I did some digging. I think the trigger is actually quite clear: UpdateWriteDesiredSize was only called on ack, but the stream window is extended independently of acks. A peer can ack all our data, wait (all data acked but zero window available) and then extend the window size to allow more data later - so we do need to update desired size based on the window update alone 👍. Good find @martenrichter! This is tricky to trigger as it's easily obscured by buffering.

We can repro it reliably with something like this:

import{createPrivateKey}from'node:crypto';import{readFile}from'node:fs/promises';import{setTimeoutassleep}from'node:timers/promises';import{listen,connect}from'node:quic';import{drainableProtocol}from'stream/iter';constkeys='test/fixtures/keys';constkey=createPrivateKey(awaitreadFile(`${keys}/agent1-key.pem`));constcert=awaitreadFile(`${keys}/agent1-cert.pem`);constWINDOW=4096;// Fills the window exactly: HTTP/3 spends 11 of those bytes on framing (8 for// the HEADERS frame below, 3 for the DATA frame header). The send buffer then// empties at the same moment the window reaches zero, leaving nothing in// flight to ack. Any other size leaves bytes queued, and the ack for those// wakes the writer instead, hiding the bug.constBODY=WINDOW-11;letletServerRead;constserverMayRead=newPromise((resolve)=>{letServerRead=resolve;});constendpoint=awaitlisten((session)=>{session.onstream=async(stream)=>{awaitserverMayRead;forawait(const_ofstream){/* reading extends the window */}};},{sni: {'*': {keys: [key],certs: [cert]}},transportParams: {initialMaxStreamDataBidiRemote: WINDOW,initialMaxData: 1024*1024,},onheaders(){this.sendHeaders({':status': '200'});},});constsession=awaitconnect(endpoint.address,{servername: 'localhost',verifyPeer: 'manual',});awaitsession.opened;// Budget well above the window, so the window is what stops the writer.conststream=awaitsession.createBidirectionalStream({budget: 1024*1024});stream.sendHeaders({':method': 'POST',':path': '/',':scheme': 'https',':authority': 'localhost',},{terminal: false});constwriter=stream.writer;writer.writeSync(newUint8Array(BODY));// Long enough for every byte to be acked. The peer acks as data arrives,// whether or not its application has read any of it, so by now the window is// exhausted, the send buffer is empty, and no further ACK can arrive.awaitsleep(500);console.log('all acked, window exhausted');constwatchdog=setTimeout(()=>{console.log('STALLED: no drain after MAX_STREAM_DATA');process.exit(1);},5000);letServerRead();// extend the window, with no ack attachedconsole.log('window extended');awaitwriter[drainableProtocol]();console.log('writer drain');clearTimeout(watchdog);console.log('done');process.exit(0);

This creates a server which doesn't read, so it'll ack everything without extending the window. The client writes the exact amount to fill the window but leave nothing in its buffers (otherwise the window update triggers more writes, and then gets acks). Then after a 500ms pause, the server reads and triggers a window update.

Fixed client will trigger a drain and complete OK, bad client will stall forever. We should be able to build a test around that directly.

The fix here covers this for HTTP/3, but doesn't totally fix the issue because we have two independent implementations of this with the current application structure, so we'll need to also separately fix the equivalent issue again for pure QUIC in the default app.

[martenrichter]

And we may also need it for session window, but I think we also need a callback from ngtcp2 for this.
Btw. that is the reason why there was so little progress from the last 3 weekends, it was horrible to debug (and I had a second error in the client code that was interfering).

[martenrichter]

@pimterry I am tring to integrate your test. But actually, the bug I was catching was different; it was actually two buffers, one inside the window size and the other going beyond the window size. At least this what I remember from debugging.

[martenrichter]

Ok, also done for pure quic.
What is missing though, is the same for maxdata.
So I think we should create a separate issue for this with test, but I do not see a fix, as the ngtcp2 callback is missing.
I am refering to this line:

node/src/quic/streams.cc

Line 1873 in 41525ab

uint64_t conn_left = ngtcp2_conn_get_max_data_left(conn);

it is less likely to cause a stall, but it may happen.

[martenrichter]

Create a separate issue for maxdata, as I have no clue how to address it currently.
#64835

[nodejs-github-bot]

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

[trivikr]

It looks like this PR is ready to land.

[nodejs-github-bot]

Commit Queue failed

- Loading data for nodejs/node/pull/64768
✔ Done loading data for nodejs/node/pull/64768
----------------------------------- PR info ------------------------------------
Title quic: write desired size needs update on maxstream (#64768)
⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!
Branch martenrichter:writedesired -> nodejs:main
Labels c++, needs-ci, quic, commit-queue, commit-queue-squash
Commits 10
- quic: write desired size needs update on maxstream
- quic: Fix lint
- quic: add test for maxstreamdata buffer stalls
- quic: rename test
- quic: fix streamaxdata for non http/3
- quic: Fix lint
- quic: fix lint
- Fix lint2
- Fix lint 3
- Fix lint 4
Committers 2
- Marten Richter <marten.richter@tu-berlin.de>
- Marten Richter <marten.richter@freenet.de>
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
------------------------------ Generated metadata ------------------------------
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
--------------------------------------------------------------------------------
ℹ This PR was created on Sun, 26 Jul 2026 20:26:23 GMT
✔ Approvals: 1
✔ - James M Snell (@jasnell) (TSC): https://github.com/nodejs/node/pull/64768#pullrequestreview-4889028017
✘ GitHub CI is still running
ℹ Last Full PR CI on 2026-08-20T03:22:16Z: https://ci.nodejs.org/job/node-test-pull-request/76030/
- Querying data for job/node-test-pull-request/76030/
✔ Build data downloaded
✔ Last Jenkins CI successful
--------------------------------------------------------------------------------
✔ Aborted `git node land` session in /home/runner/work/node/node/.ncu

https://github.com/nodejs/node/actions/runs/32384310354

[martenrichter]

It says: "⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!"
I wonder what this means. PR worked before for me with node.js .

[jasnell]

I wouldn't worry about that. I'll squash and merge these directly.

[jasnell]

Landed in 2bfc1e9

[martenrichter]

Without this update the streams can stall, if the chunks are close or bigger than the window size.
It was provoked by a very special timing, so probably hard to test,
Though I do not know, if this is also required for max data of the whole session.
Upstream says no:
ngtcp2/ngtcp2#2243

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[martenrichter]

@jasnell@pimterry can you have a look?

[avivkeller]

Can you add a test?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.14%. Comparing base (9024119) to head (ad505ca).
⚠️ Report is 411 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #64768 +/- ##
==========================================
- Coverage 90.15% 90.14% -0.01% 
==========================================
Files 743 746 +3 Lines 242407 242660 +253 Branches 45645 45723 +78 ==========================================
+ Hits 218532 218750 +218 - Misses 15357 15425 +68 + Partials 8518 8485 -33 

see 55 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.

[martenrichter]

Can you add a test?

Not really. I found it in my webtransport test suite. But there it happens only, if I use node.js server and client. If I choose a Quiche client and a Node.js server, or a Node.js client and a Quiche server, it does not surface, as it depends on the particular packet size the particular Quic internals are generating at the low level. But I will later port all of my wt tests over, but therefore wt must be ready. (But this must not mean that these would reliably trigger the issue).

[pimterry]

Not really. I found it in my webtransport test suite.

I wanted to understand, so I did some digging. I think the trigger is actually quite clear: UpdateWriteDesiredSize was only called on ack, but the stream window is extended independently of acks. A peer can ack all our data, wait (all data acked but zero window available) and then extend the window size to allow more data later - so we do need to update desired size based on the window update alone 👍. Good find @martenrichter! This is tricky to trigger as it's easily obscured by buffering.

We can repro it reliably with something like this:

import{createPrivateKey}from'node:crypto';import{readFile}from'node:fs/promises';import{setTimeoutassleep}from'node:timers/promises';import{listen,connect}from'node:quic';import{drainableProtocol}from'stream/iter';constkeys='test/fixtures/keys';constkey=createPrivateKey(awaitreadFile(`${keys}/agent1-key.pem`));constcert=awaitreadFile(`${keys}/agent1-cert.pem`);constWINDOW=4096;// Fills the window exactly: HTTP/3 spends 11 of those bytes on framing (8 for// the HEADERS frame below, 3 for the DATA frame header). The send buffer then// empties at the same moment the window reaches zero, leaving nothing in// flight to ack. Any other size leaves bytes queued, and the ack for those// wakes the writer instead, hiding the bug.constBODY=WINDOW-11;letletServerRead;constserverMayRead=newPromise((resolve)=>{letServerRead=resolve;});constendpoint=awaitlisten((session)=>{session.onstream=async(stream)=>{awaitserverMayRead;forawait(const_ofstream){/* reading extends the window */}};},{sni: {'*': {keys: [key],certs: [cert]}},transportParams: {initialMaxStreamDataBidiRemote: WINDOW,initialMaxData: 1024*1024,},onheaders(){this.sendHeaders({':status': '200'});},});constsession=awaitconnect(endpoint.address,{servername: 'localhost',verifyPeer: 'manual',});awaitsession.opened;// Budget well above the window, so the window is what stops the writer.conststream=awaitsession.createBidirectionalStream({budget: 1024*1024});stream.sendHeaders({':method': 'POST',':path': '/',':scheme': 'https',':authority': 'localhost',},{terminal: false});constwriter=stream.writer;writer.writeSync(newUint8Array(BODY));// Long enough for every byte to be acked. The peer acks as data arrives,// whether or not its application has read any of it, so by now the window is// exhausted, the send buffer is empty, and no further ACK can arrive.awaitsleep(500);console.log('all acked, window exhausted');constwatchdog=setTimeout(()=>{console.log('STALLED: no drain after MAX_STREAM_DATA');process.exit(1);},5000);letServerRead();// extend the window, with no ack attachedconsole.log('window extended');awaitwriter[drainableProtocol]();console.log('writer drain');clearTimeout(watchdog);console.log('done');process.exit(0);

This creates a server which doesn't read, so it'll ack everything without extending the window. The client writes the exact amount to fill the window but leave nothing in its buffers (otherwise the window update triggers more writes, and then gets acks). Then after a 500ms pause, the server reads and triggers a window update.

Fixed client will trigger a drain and complete OK, bad client will stall forever. We should be able to build a test around that directly.

The fix here covers this for HTTP/3, but doesn't totally fix the issue because we have two independent implementations of this with the current application structure, so we'll need to also separately fix the equivalent issue again for pure QUIC in the default app.

[martenrichter]

And we may also need it for session window, but I think we also need a callback from ngtcp2 for this.
Btw. that is the reason why there was so little progress from the last 3 weekends, it was horrible to debug (and I had a second error in the client code that was interfering).

[martenrichter]

@pimterry I am tring to integrate your test. But actually, the bug I was catching was different; it was actually two buffers, one inside the window size and the other going beyond the window size. At least this what I remember from debugging.

[martenrichter]

Ok, also done for pure quic.
What is missing though, is the same for maxdata.
So I think we should create a separate issue for this with test, but I do not see a fix, as the ngtcp2 callback is missing.
I am refering to this line:

node/src/quic/streams.cc

Line 1873 in 41525ab

uint64_t conn_left = ngtcp2_conn_get_max_data_left(conn);

it is less likely to cause a stall, but it may happen.

[martenrichter]

Create a separate issue for maxdata, as I have no clue how to address it currently.
#64835

[nodejs-github-bot]

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

[trivikr]

It looks like this PR is ready to land.

[nodejs-github-bot]

Commit Queue failed

- Loading data for nodejs/node/pull/64768
✔ Done loading data for nodejs/node/pull/64768
----------------------------------- PR info ------------------------------------
Title quic: write desired size needs update on maxstream (#64768)
⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!
Branch martenrichter:writedesired -> nodejs:main
Labels c++, needs-ci, quic, commit-queue, commit-queue-squash
Commits 10
- quic: write desired size needs update on maxstream
- quic: Fix lint
- quic: add test for maxstreamdata buffer stalls
- quic: rename test
- quic: fix streamaxdata for non http/3
- quic: Fix lint
- quic: fix lint
- Fix lint2
- Fix lint 3
- Fix lint 4
Committers 2
- Marten Richter <marten.richter@tu-berlin.de>
- Marten Richter <marten.richter@freenet.de>
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
------------------------------ Generated metadata ------------------------------
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
--------------------------------------------------------------------------------
ℹ This PR was created on Sun, 26 Jul 2026 20:26:23 GMT
✔ Approvals: 1
✔ - James M Snell (@jasnell) (TSC): https://github.com/nodejs/node/pull/64768#pullrequestreview-4889028017
✘ GitHub CI is still running
ℹ Last Full PR CI on 2026-08-20T03:22:16Z: https://ci.nodejs.org/job/node-test-pull-request/76030/
- Querying data for job/node-test-pull-request/76030/
✔ Build data downloaded
✔ Last Jenkins CI successful
--------------------------------------------------------------------------------
✔ Aborted `git node land` session in /home/runner/work/node/node/.ncu

https://github.com/nodejs/node/actions/runs/32384310354

[martenrichter]

It says: "⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!"
I wonder what this means. PR worked before for me with node.js .

[jasnell]

I wouldn't worry about that. I'll squash and merge these directly.

[jasnell]

Landed in 2bfc1e9

[martenrichter]

Without this update the streams can stall, if the chunks are close or bigger than the window size.
It was provoked by a very special timing, so probably hard to test,
Though I do not know, if this is also required for max data of the whole session.
Upstream says no:
ngtcp2/ngtcp2#2243

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[martenrichter]

@jasnell@pimterry can you have a look?

[avivkeller]

Can you add a test?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.14%. Comparing base (9024119) to head (ad505ca).
⚠️ Report is 411 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #64768 +/- ##
==========================================
- Coverage 90.15% 90.14% -0.01% 
==========================================
Files 743 746 +3 Lines 242407 242660 +253 Branches 45645 45723 +78 ==========================================
+ Hits 218532 218750 +218 - Misses 15357 15425 +68 + Partials 8518 8485 -33 

see 55 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.

[martenrichter]

Can you add a test?

Not really. I found it in my webtransport test suite. But there it happens only, if I use node.js server and client. If I choose a Quiche client and a Node.js server, or a Node.js client and a Quiche server, it does not surface, as it depends on the particular packet size the particular Quic internals are generating at the low level. But I will later port all of my wt tests over, but therefore wt must be ready. (But this must not mean that these would reliably trigger the issue).

[pimterry]

Not really. I found it in my webtransport test suite.

I wanted to understand, so I did some digging. I think the trigger is actually quite clear: UpdateWriteDesiredSize was only called on ack, but the stream window is extended independently of acks. A peer can ack all our data, wait (all data acked but zero window available) and then extend the window size to allow more data later - so we do need to update desired size based on the window update alone 👍. Good find @martenrichter! This is tricky to trigger as it's easily obscured by buffering.

We can repro it reliably with something like this:

import{createPrivateKey}from'node:crypto';import{readFile}from'node:fs/promises';import{setTimeoutassleep}from'node:timers/promises';import{listen,connect}from'node:quic';import{drainableProtocol}from'stream/iter';constkeys='test/fixtures/keys';constkey=createPrivateKey(awaitreadFile(`${keys}/agent1-key.pem`));constcert=awaitreadFile(`${keys}/agent1-cert.pem`);constWINDOW=4096;// Fills the window exactly: HTTP/3 spends 11 of those bytes on framing (8 for// the HEADERS frame below, 3 for the DATA frame header). The send buffer then// empties at the same moment the window reaches zero, leaving nothing in// flight to ack. Any other size leaves bytes queued, and the ack for those// wakes the writer instead, hiding the bug.constBODY=WINDOW-11;letletServerRead;constserverMayRead=newPromise((resolve)=>{letServerRead=resolve;});constendpoint=awaitlisten((session)=>{session.onstream=async(stream)=>{awaitserverMayRead;forawait(const_ofstream){/* reading extends the window */}};},{sni: {'*': {keys: [key],certs: [cert]}},transportParams: {initialMaxStreamDataBidiRemote: WINDOW,initialMaxData: 1024*1024,},onheaders(){this.sendHeaders({':status': '200'});},});constsession=awaitconnect(endpoint.address,{servername: 'localhost',verifyPeer: 'manual',});awaitsession.opened;// Budget well above the window, so the window is what stops the writer.conststream=awaitsession.createBidirectionalStream({budget: 1024*1024});stream.sendHeaders({':method': 'POST',':path': '/',':scheme': 'https',':authority': 'localhost',},{terminal: false});constwriter=stream.writer;writer.writeSync(newUint8Array(BODY));// Long enough for every byte to be acked. The peer acks as data arrives,// whether or not its application has read any of it, so by now the window is// exhausted, the send buffer is empty, and no further ACK can arrive.awaitsleep(500);console.log('all acked, window exhausted');constwatchdog=setTimeout(()=>{console.log('STALLED: no drain after MAX_STREAM_DATA');process.exit(1);},5000);letServerRead();// extend the window, with no ack attachedconsole.log('window extended');awaitwriter[drainableProtocol]();console.log('writer drain');clearTimeout(watchdog);console.log('done');process.exit(0);

This creates a server which doesn't read, so it'll ack everything without extending the window. The client writes the exact amount to fill the window but leave nothing in its buffers (otherwise the window update triggers more writes, and then gets acks). Then after a 500ms pause, the server reads and triggers a window update.

Fixed client will trigger a drain and complete OK, bad client will stall forever. We should be able to build a test around that directly.

The fix here covers this for HTTP/3, but doesn't totally fix the issue because we have two independent implementations of this with the current application structure, so we'll need to also separately fix the equivalent issue again for pure QUIC in the default app.

[martenrichter]

And we may also need it for session window, but I think we also need a callback from ngtcp2 for this.
Btw. that is the reason why there was so little progress from the last 3 weekends, it was horrible to debug (and I had a second error in the client code that was interfering).

[martenrichter]

@pimterry I am tring to integrate your test. But actually, the bug I was catching was different; it was actually two buffers, one inside the window size and the other going beyond the window size. At least this what I remember from debugging.

[martenrichter]

Ok, also done for pure quic.
What is missing though, is the same for maxdata.
So I think we should create a separate issue for this with test, but I do not see a fix, as the ngtcp2 callback is missing.
I am refering to this line:

node/src/quic/streams.cc

Line 1873 in 41525ab

uint64_t conn_left = ngtcp2_conn_get_max_data_left(conn);

it is less likely to cause a stall, but it may happen.

[martenrichter]

Create a separate issue for maxdata, as I have no clue how to address it currently.
#64835

[nodejs-github-bot]

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

[trivikr]

It looks like this PR is ready to land.

[nodejs-github-bot]

Commit Queue failed

- Loading data for nodejs/node/pull/64768
✔ Done loading data for nodejs/node/pull/64768
----------------------------------- PR info ------------------------------------
Title quic: write desired size needs update on maxstream (#64768)
⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!
Branch martenrichter:writedesired -> nodejs:main
Labels c++, needs-ci, quic, commit-queue, commit-queue-squash
Commits 10
- quic: write desired size needs update on maxstream
- quic: Fix lint
- quic: add test for maxstreamdata buffer stalls
- quic: rename test
- quic: fix streamaxdata for non http/3
- quic: Fix lint
- quic: fix lint
- Fix lint2
- Fix lint 3
- Fix lint 4
Committers 2
- Marten Richter <marten.richter@tu-berlin.de>
- Marten Richter <marten.richter@freenet.de>
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
------------------------------ Generated metadata ------------------------------
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
--------------------------------------------------------------------------------
ℹ This PR was created on Sun, 26 Jul 2026 20:26:23 GMT
✔ Approvals: 1
✔ - James M Snell (@jasnell) (TSC): https://github.com/nodejs/node/pull/64768#pullrequestreview-4889028017
✘ GitHub CI is still running
ℹ Last Full PR CI on 2026-08-20T03:22:16Z: https://ci.nodejs.org/job/node-test-pull-request/76030/
- Querying data for job/node-test-pull-request/76030/
✔ Build data downloaded
✔ Last Jenkins CI successful
--------------------------------------------------------------------------------
✔ Aborted `git node land` session in /home/runner/work/node/node/.ncu

https://github.com/nodejs/node/actions/runs/32384310354

[martenrichter]

It says: "⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!"
I wonder what this means. PR worked before for me with node.js .

[jasnell]

I wouldn't worry about that. I'll squash and merge these directly.

[jasnell]

Landed in 2bfc1e9

[martenrichter]

Without this update the streams can stall, if the chunks are close or bigger than the window size.
It was provoked by a very special timing, so probably hard to test,
Though I do not know, if this is also required for max data of the whole session.
Upstream says no:
ngtcp2/ngtcp2#2243

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[martenrichter]

@jasnell@pimterry can you have a look?

[avivkeller]

Can you add a test?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.14%. Comparing base (9024119) to head (ad505ca).
⚠️ Report is 411 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #64768 +/- ##
==========================================
- Coverage 90.15% 90.14% -0.01% 
==========================================
Files 743 746 +3 Lines 242407 242660 +253 Branches 45645 45723 +78 ==========================================
+ Hits 218532 218750 +218 - Misses 15357 15425 +68 + Partials 8518 8485 -33 

see 55 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.

[martenrichter]

Can you add a test?

Not really. I found it in my webtransport test suite. But there it happens only, if I use node.js server and client. If I choose a Quiche client and a Node.js server, or a Node.js client and a Quiche server, it does not surface, as it depends on the particular packet size the particular Quic internals are generating at the low level. But I will later port all of my wt tests over, but therefore wt must be ready. (But this must not mean that these would reliably trigger the issue).

[pimterry]

Not really. I found it in my webtransport test suite.

I wanted to understand, so I did some digging. I think the trigger is actually quite clear: UpdateWriteDesiredSize was only called on ack, but the stream window is extended independently of acks. A peer can ack all our data, wait (all data acked but zero window available) and then extend the window size to allow more data later - so we do need to update desired size based on the window update alone 👍. Good find @martenrichter! This is tricky to trigger as it's easily obscured by buffering.

We can repro it reliably with something like this:

import{createPrivateKey}from'node:crypto';import{readFile}from'node:fs/promises';import{setTimeoutassleep}from'node:timers/promises';import{listen,connect}from'node:quic';import{drainableProtocol}from'stream/iter';constkeys='test/fixtures/keys';constkey=createPrivateKey(awaitreadFile(`${keys}/agent1-key.pem`));constcert=awaitreadFile(`${keys}/agent1-cert.pem`);constWINDOW=4096;// Fills the window exactly: HTTP/3 spends 11 of those bytes on framing (8 for// the HEADERS frame below, 3 for the DATA frame header). The send buffer then// empties at the same moment the window reaches zero, leaving nothing in// flight to ack. Any other size leaves bytes queued, and the ack for those// wakes the writer instead, hiding the bug.constBODY=WINDOW-11;letletServerRead;constserverMayRead=newPromise((resolve)=>{letServerRead=resolve;});constendpoint=awaitlisten((session)=>{session.onstream=async(stream)=>{awaitserverMayRead;forawait(const_ofstream){/* reading extends the window */}};},{sni: {'*': {keys: [key],certs: [cert]}},transportParams: {initialMaxStreamDataBidiRemote: WINDOW,initialMaxData: 1024*1024,},onheaders(){this.sendHeaders({':status': '200'});},});constsession=awaitconnect(endpoint.address,{servername: 'localhost',verifyPeer: 'manual',});awaitsession.opened;// Budget well above the window, so the window is what stops the writer.conststream=awaitsession.createBidirectionalStream({budget: 1024*1024});stream.sendHeaders({':method': 'POST',':path': '/',':scheme': 'https',':authority': 'localhost',},{terminal: false});constwriter=stream.writer;writer.writeSync(newUint8Array(BODY));// Long enough for every byte to be acked. The peer acks as data arrives,// whether or not its application has read any of it, so by now the window is// exhausted, the send buffer is empty, and no further ACK can arrive.awaitsleep(500);console.log('all acked, window exhausted');constwatchdog=setTimeout(()=>{console.log('STALLED: no drain after MAX_STREAM_DATA');process.exit(1);},5000);letServerRead();// extend the window, with no ack attachedconsole.log('window extended');awaitwriter[drainableProtocol]();console.log('writer drain');clearTimeout(watchdog);console.log('done');process.exit(0);

This creates a server which doesn't read, so it'll ack everything without extending the window. The client writes the exact amount to fill the window but leave nothing in its buffers (otherwise the window update triggers more writes, and then gets acks). Then after a 500ms pause, the server reads and triggers a window update.

Fixed client will trigger a drain and complete OK, bad client will stall forever. We should be able to build a test around that directly.

The fix here covers this for HTTP/3, but doesn't totally fix the issue because we have two independent implementations of this with the current application structure, so we'll need to also separately fix the equivalent issue again for pure QUIC in the default app.

[martenrichter]

And we may also need it for session window, but I think we also need a callback from ngtcp2 for this.
Btw. that is the reason why there was so little progress from the last 3 weekends, it was horrible to debug (and I had a second error in the client code that was interfering).

[martenrichter]

@pimterry I am tring to integrate your test. But actually, the bug I was catching was different; it was actually two buffers, one inside the window size and the other going beyond the window size. At least this what I remember from debugging.

[martenrichter]

Ok, also done for pure quic.
What is missing though, is the same for maxdata.
So I think we should create a separate issue for this with test, but I do not see a fix, as the ngtcp2 callback is missing.
I am refering to this line:

node/src/quic/streams.cc

Line 1873 in 41525ab

uint64_t conn_left = ngtcp2_conn_get_max_data_left(conn);

it is less likely to cause a stall, but it may happen.

[martenrichter]

Create a separate issue for maxdata, as I have no clue how to address it currently.
#64835

[nodejs-github-bot]

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

[trivikr]

It looks like this PR is ready to land.

[nodejs-github-bot]

Commit Queue failed

- Loading data for nodejs/node/pull/64768
✔ Done loading data for nodejs/node/pull/64768
----------------------------------- PR info ------------------------------------
Title quic: write desired size needs update on maxstream (#64768)
⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!
Branch martenrichter:writedesired -> nodejs:main
Labels c++, needs-ci, quic, commit-queue, commit-queue-squash
Commits 10
- quic: write desired size needs update on maxstream
- quic: Fix lint
- quic: add test for maxstreamdata buffer stalls
- quic: rename test
- quic: fix streamaxdata for non http/3
- quic: Fix lint
- quic: fix lint
- Fix lint2
- Fix lint 3
- Fix lint 4
Committers 2
- Marten Richter <marten.richter@tu-berlin.de>
- Marten Richter <marten.richter@freenet.de>
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
------------------------------ Generated metadata ------------------------------
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
--------------------------------------------------------------------------------
ℹ This PR was created on Sun, 26 Jul 2026 20:26:23 GMT
✔ Approvals: 1
✔ - James M Snell (@jasnell) (TSC): https://github.com/nodejs/node/pull/64768#pullrequestreview-4889028017
✘ GitHub CI is still running
ℹ Last Full PR CI on 2026-08-20T03:22:16Z: https://ci.nodejs.org/job/node-test-pull-request/76030/
- Querying data for job/node-test-pull-request/76030/
✔ Build data downloaded
✔ Last Jenkins CI successful
--------------------------------------------------------------------------------
✔ Aborted `git node land` session in /home/runner/work/node/node/.ncu

https://github.com/nodejs/node/actions/runs/32384310354

[martenrichter]

It says: "⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!"
I wonder what this means. PR worked before for me with node.js .

[jasnell]

I wouldn't worry about that. I'll squash and merge these directly.

[jasnell]

Landed in 2bfc1e9

[martenrichter]

Without this update the streams can stall, if the chunks are close or bigger than the window size.
It was provoked by a very special timing, so probably hard to test,
Though I do not know, if this is also required for max data of the whole session.
Upstream says no:
ngtcp2/ngtcp2#2243

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[martenrichter]

@jasnell@pimterry can you have a look?

[avivkeller]

Can you add a test?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.14%. Comparing base (9024119) to head (ad505ca).
⚠️ Report is 411 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #64768 +/- ##
==========================================
- Coverage 90.15% 90.14% -0.01% 
==========================================
Files 743 746 +3 Lines 242407 242660 +253 Branches 45645 45723 +78 ==========================================
+ Hits 218532 218750 +218 - Misses 15357 15425 +68 + Partials 8518 8485 -33 

see 55 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.

[martenrichter]

Can you add a test?

Not really. I found it in my webtransport test suite. But there it happens only, if I use node.js server and client. If I choose a Quiche client and a Node.js server, or a Node.js client and a Quiche server, it does not surface, as it depends on the particular packet size the particular Quic internals are generating at the low level. But I will later port all of my wt tests over, but therefore wt must be ready. (But this must not mean that these would reliably trigger the issue).

[pimterry]

Not really. I found it in my webtransport test suite.

I wanted to understand, so I did some digging. I think the trigger is actually quite clear: UpdateWriteDesiredSize was only called on ack, but the stream window is extended independently of acks. A peer can ack all our data, wait (all data acked but zero window available) and then extend the window size to allow more data later - so we do need to update desired size based on the window update alone 👍. Good find @martenrichter! This is tricky to trigger as it's easily obscured by buffering.

We can repro it reliably with something like this:

import{createPrivateKey}from'node:crypto';import{readFile}from'node:fs/promises';import{setTimeoutassleep}from'node:timers/promises';import{listen,connect}from'node:quic';import{drainableProtocol}from'stream/iter';constkeys='test/fixtures/keys';constkey=createPrivateKey(awaitreadFile(`${keys}/agent1-key.pem`));constcert=awaitreadFile(`${keys}/agent1-cert.pem`);constWINDOW=4096;// Fills the window exactly: HTTP/3 spends 11 of those bytes on framing (8 for// the HEADERS frame below, 3 for the DATA frame header). The send buffer then// empties at the same moment the window reaches zero, leaving nothing in// flight to ack. Any other size leaves bytes queued, and the ack for those// wakes the writer instead, hiding the bug.constBODY=WINDOW-11;letletServerRead;constserverMayRead=newPromise((resolve)=>{letServerRead=resolve;});constendpoint=awaitlisten((session)=>{session.onstream=async(stream)=>{awaitserverMayRead;forawait(const_ofstream){/* reading extends the window */}};},{sni: {'*': {keys: [key],certs: [cert]}},transportParams: {initialMaxStreamDataBidiRemote: WINDOW,initialMaxData: 1024*1024,},onheaders(){this.sendHeaders({':status': '200'});},});constsession=awaitconnect(endpoint.address,{servername: 'localhost',verifyPeer: 'manual',});awaitsession.opened;// Budget well above the window, so the window is what stops the writer.conststream=awaitsession.createBidirectionalStream({budget: 1024*1024});stream.sendHeaders({':method': 'POST',':path': '/',':scheme': 'https',':authority': 'localhost',},{terminal: false});constwriter=stream.writer;writer.writeSync(newUint8Array(BODY));// Long enough for every byte to be acked. The peer acks as data arrives,// whether or not its application has read any of it, so by now the window is// exhausted, the send buffer is empty, and no further ACK can arrive.awaitsleep(500);console.log('all acked, window exhausted');constwatchdog=setTimeout(()=>{console.log('STALLED: no drain after MAX_STREAM_DATA');process.exit(1);},5000);letServerRead();// extend the window, with no ack attachedconsole.log('window extended');awaitwriter[drainableProtocol]();console.log('writer drain');clearTimeout(watchdog);console.log('done');process.exit(0);

This creates a server which doesn't read, so it'll ack everything without extending the window. The client writes the exact amount to fill the window but leave nothing in its buffers (otherwise the window update triggers more writes, and then gets acks). Then after a 500ms pause, the server reads and triggers a window update.

Fixed client will trigger a drain and complete OK, bad client will stall forever. We should be able to build a test around that directly.

The fix here covers this for HTTP/3, but doesn't totally fix the issue because we have two independent implementations of this with the current application structure, so we'll need to also separately fix the equivalent issue again for pure QUIC in the default app.

[martenrichter]

And we may also need it for session window, but I think we also need a callback from ngtcp2 for this.
Btw. that is the reason why there was so little progress from the last 3 weekends, it was horrible to debug (and I had a second error in the client code that was interfering).

[martenrichter]

@pimterry I am tring to integrate your test. But actually, the bug I was catching was different; it was actually two buffers, one inside the window size and the other going beyond the window size. At least this what I remember from debugging.

[martenrichter]

Ok, also done for pure quic.
What is missing though, is the same for maxdata.
So I think we should create a separate issue for this with test, but I do not see a fix, as the ngtcp2 callback is missing.
I am refering to this line:

node/src/quic/streams.cc

Line 1873 in 41525ab

uint64_t conn_left = ngtcp2_conn_get_max_data_left(conn);

it is less likely to cause a stall, but it may happen.

[martenrichter]

Create a separate issue for maxdata, as I have no clue how to address it currently.
#64835

[nodejs-github-bot]

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

[trivikr]

It looks like this PR is ready to land.

[nodejs-github-bot]

Commit Queue failed

- Loading data for nodejs/node/pull/64768
✔ Done loading data for nodejs/node/pull/64768
----------------------------------- PR info ------------------------------------
Title quic: write desired size needs update on maxstream (#64768)
⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!
Branch martenrichter:writedesired -> nodejs:main
Labels c++, needs-ci, quic, commit-queue, commit-queue-squash
Commits 10
- quic: write desired size needs update on maxstream
- quic: Fix lint
- quic: add test for maxstreamdata buffer stalls
- quic: rename test
- quic: fix streamaxdata for non http/3
- quic: Fix lint
- quic: fix lint
- Fix lint2
- Fix lint 3
- Fix lint 4
Committers 2
- Marten Richter <marten.richter@tu-berlin.de>
- Marten Richter <marten.richter@freenet.de>
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
------------------------------ Generated metadata ------------------------------
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
--------------------------------------------------------------------------------
ℹ This PR was created on Sun, 26 Jul 2026 20:26:23 GMT
✔ Approvals: 1
✔ - James M Snell (@jasnell) (TSC): https://github.com/nodejs/node/pull/64768#pullrequestreview-4889028017
✘ GitHub CI is still running
ℹ Last Full PR CI on 2026-08-20T03:22:16Z: https://ci.nodejs.org/job/node-test-pull-request/76030/
- Querying data for job/node-test-pull-request/76030/
✔ Build data downloaded
✔ Last Jenkins CI successful
--------------------------------------------------------------------------------
✔ Aborted `git node land` session in /home/runner/work/node/node/.ncu

https://github.com/nodejs/node/actions/runs/32384310354

[martenrichter]

It says: "⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!"
I wonder what this means. PR worked before for me with node.js .

[jasnell]

I wouldn't worry about that. I'll squash and merge these directly.

[jasnell]

Landed in 2bfc1e9

[martenrichter]

Without this update the streams can stall, if the chunks are close or bigger than the window size.
It was provoked by a very special timing, so probably hard to test,
Though I do not know, if this is also required for max data of the whole session.
Upstream says no:
ngtcp2/ngtcp2#2243

[nodejs-github-bot]

Review requested:

• @nodejs/quic

[martenrichter]

@jasnell@pimterry can you have a look?

[avivkeller]

Can you add a test?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.14%. Comparing base (9024119) to head (ad505ca).
⚠️ Report is 411 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #64768 +/- ##
==========================================
- Coverage 90.15% 90.14% -0.01% 
==========================================
Files 743 746 +3 Lines 242407 242660 +253 Branches 45645 45723 +78 ==========================================
+ Hits 218532 218750 +218 - Misses 15357 15425 +68 + Partials 8518 8485 -33 

see 55 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.

[martenrichter]

Can you add a test?

Not really. I found it in my webtransport test suite. But there it happens only, if I use node.js server and client. If I choose a Quiche client and a Node.js server, or a Node.js client and a Quiche server, it does not surface, as it depends on the particular packet size the particular Quic internals are generating at the low level. But I will later port all of my wt tests over, but therefore wt must be ready. (But this must not mean that these would reliably trigger the issue).

[pimterry]

Not really. I found it in my webtransport test suite.

I wanted to understand, so I did some digging. I think the trigger is actually quite clear: UpdateWriteDesiredSize was only called on ack, but the stream window is extended independently of acks. A peer can ack all our data, wait (all data acked but zero window available) and then extend the window size to allow more data later - so we do need to update desired size based on the window update alone 👍. Good find @martenrichter! This is tricky to trigger as it's easily obscured by buffering.

We can repro it reliably with something like this:

import{createPrivateKey}from'node:crypto';import{readFile}from'node:fs/promises';import{setTimeoutassleep}from'node:timers/promises';import{listen,connect}from'node:quic';import{drainableProtocol}from'stream/iter';constkeys='test/fixtures/keys';constkey=createPrivateKey(awaitreadFile(`${keys}/agent1-key.pem`));constcert=awaitreadFile(`${keys}/agent1-cert.pem`);constWINDOW=4096;// Fills the window exactly: HTTP/3 spends 11 of those bytes on framing (8 for// the HEADERS frame below, 3 for the DATA frame header). The send buffer then// empties at the same moment the window reaches zero, leaving nothing in// flight to ack. Any other size leaves bytes queued, and the ack for those// wakes the writer instead, hiding the bug.constBODY=WINDOW-11;letletServerRead;constserverMayRead=newPromise((resolve)=>{letServerRead=resolve;});constendpoint=awaitlisten((session)=>{session.onstream=async(stream)=>{awaitserverMayRead;forawait(const_ofstream){/* reading extends the window */}};},{sni: {'*': {keys: [key],certs: [cert]}},transportParams: {initialMaxStreamDataBidiRemote: WINDOW,initialMaxData: 1024*1024,},onheaders(){this.sendHeaders({':status': '200'});},});constsession=awaitconnect(endpoint.address,{servername: 'localhost',verifyPeer: 'manual',});awaitsession.opened;// Budget well above the window, so the window is what stops the writer.conststream=awaitsession.createBidirectionalStream({budget: 1024*1024});stream.sendHeaders({':method': 'POST',':path': '/',':scheme': 'https',':authority': 'localhost',},{terminal: false});constwriter=stream.writer;writer.writeSync(newUint8Array(BODY));// Long enough for every byte to be acked. The peer acks as data arrives,// whether or not its application has read any of it, so by now the window is// exhausted, the send buffer is empty, and no further ACK can arrive.awaitsleep(500);console.log('all acked, window exhausted');constwatchdog=setTimeout(()=>{console.log('STALLED: no drain after MAX_STREAM_DATA');process.exit(1);},5000);letServerRead();// extend the window, with no ack attachedconsole.log('window extended');awaitwriter[drainableProtocol]();console.log('writer drain');clearTimeout(watchdog);console.log('done');process.exit(0);

This creates a server which doesn't read, so it'll ack everything without extending the window. The client writes the exact amount to fill the window but leave nothing in its buffers (otherwise the window update triggers more writes, and then gets acks). Then after a 500ms pause, the server reads and triggers a window update.

Fixed client will trigger a drain and complete OK, bad client will stall forever. We should be able to build a test around that directly.

The fix here covers this for HTTP/3, but doesn't totally fix the issue because we have two independent implementations of this with the current application structure, so we'll need to also separately fix the equivalent issue again for pure QUIC in the default app.

[martenrichter]

And we may also need it for session window, but I think we also need a callback from ngtcp2 for this.
Btw. that is the reason why there was so little progress from the last 3 weekends, it was horrible to debug (and I had a second error in the client code that was interfering).

[martenrichter]

@pimterry I am tring to integrate your test. But actually, the bug I was catching was different; it was actually two buffers, one inside the window size and the other going beyond the window size. At least this what I remember from debugging.

[martenrichter]

Ok, also done for pure quic.
What is missing though, is the same for maxdata.
So I think we should create a separate issue for this with test, but I do not see a fix, as the ngtcp2 callback is missing.
I am refering to this line:

node/src/quic/streams.cc

Line 1873 in 41525ab

uint64_t conn_left = ngtcp2_conn_get_max_data_left(conn);

it is less likely to cause a stall, but it may happen.

[martenrichter]

Create a separate issue for maxdata, as I have no clue how to address it currently.
#64835

[nodejs-github-bot]

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

[trivikr]

It looks like this PR is ready to land.

[nodejs-github-bot]

Commit Queue failed

- Loading data for nodejs/node/pull/64768
✔ Done loading data for nodejs/node/pull/64768
----------------------------------- PR info ------------------------------------
Title quic: write desired size needs update on maxstream (#64768)
⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!
Branch martenrichter:writedesired -> nodejs:main
Labels c++, needs-ci, quic, commit-queue, commit-queue-squash
Commits 10
- quic: write desired size needs update on maxstream
- quic: Fix lint
- quic: add test for maxstreamdata buffer stalls
- quic: rename test
- quic: fix streamaxdata for non http/3
- quic: Fix lint
- quic: fix lint
- Fix lint2
- Fix lint 3
- Fix lint 4
Committers 2
- Marten Richter <marten.richter@tu-berlin.de>
- Marten Richter <marten.richter@freenet.de>
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
------------------------------ Generated metadata ------------------------------
PR-URL: https://github.com/nodejs/node/pull/64768
Reviewed-By: James M Snell <jasnell@gmail.com>
--------------------------------------------------------------------------------
ℹ This PR was created on Sun, 26 Jul 2026 20:26:23 GMT
✔ Approvals: 1
✔ - James M Snell (@jasnell) (TSC): https://github.com/nodejs/node/pull/64768#pullrequestreview-4889028017
✘ GitHub CI is still running
ℹ Last Full PR CI on 2026-08-20T03:22:16Z: https://ci.nodejs.org/job/node-test-pull-request/76030/
- Querying data for job/node-test-pull-request/76030/
✔ Build data downloaded
✔ Last Jenkins CI successful
--------------------------------------------------------------------------------
✔ Aborted `git node land` session in /home/runner/work/node/node/.ncu

https://github.com/nodejs/node/actions/runs/32384310354

[martenrichter]

It says: "⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile!"
I wonder what this means. PR worked before for me with node.js .

[jasnell]

I wouldn't worry about that. I'll squash and merge these directly.

[jasnell]

Landed in 2bfc1e9