| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Signed-off-by: Tim Perry <pimterry@gmail.com>
|
Review requested:
|
Sorry, something went wrong.
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #64715 +/- ##
==========================================
- Coverage 90.13% 90.12% -0.02%
==========================================
Files 741 741
Lines 242251 242251
Branches 45615 45624 +9
==========================================
- Hits 218355 218319 -36
- Misses 15396 15431 +35
- Partials 8500 8501 +1 see 29 files with indirect coverage changes 🚀 New features to boost your workflow:
|
Sorry, something went wrong.
Sorry, something went wrong.
Signed-off-by: Tim Perry <pimterry@gmail.com> PR-URL: #64715 Reviewed-By: James M Snell <jasnell@gmail.com>
Signed-off-by: Tim Perry <pimterry@gmail.com> PR-URL: #64715 Reviewed-By: James M Snell <jasnell@gmail.com>
| Back | FazBrowse Home | New Git URL |
The HTTP/3 application implements StreamWriteShut to clean up streams after ngtcp2 reports NGTCP2_ERR_STREAM_SHUT_WR (generally when STOP_SENDING is received).
The default application does not. This meant it fell into a busy loop in ngtcp2 where it tried to send the data constantly in a loop forever, blocking the process. Test here reproduces this: the server accepts the stream but never reads, the client writes enough data to end up buffered, the server sends STOP_SENDING => 100% CPU never exits.
The default QUIC app now unschedules the stream when it's shut, which fixes the test.
This is largely independent of #64710. It fails with or without that change. In effect that PR changes the callback & frame-level behaviour around STOP_SENDING, while this one fixes a bug in the low-level writing behaviour for closed stream errors.