-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
delay completion of the send stream until the reset error was delivered #4445
delay completion of the send stream until the reset error was delivered #4445
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4445 +/- ##
==========================================
+ Coverage 84.75% 85.21% +0.47%
==========================================
Files 152 152
Lines 14371 14697 +326
==========================================
+ Hits 12179 12524 +345
+ Misses 1691 1673 -18
+ Partials 501 500 -1 ☔ View full report in Codecov by Sentry. |
I understand this is to avoid sending http datagrams after the stream has received STOP_SENDING. Can you elaborate on
Is the expectation that users do an empty write on the stream to know if it errors? Is it better to provide a method to retrieve the state of the stream Or just an |
How does delaying garbage collection help here? |
That's correct. On the QUIC layer, we don't need the map entry anymore. However, the upper layer has no way of discovering that QUIC garbage collected the stream, so it's impossible to keep a map at the application layer (as we need to do in HTTP/3 for datagram support) that doesn't leak (iff the error code is never read), as described in #4428.
No, that would be an awkward API indeed. For the send stream, the expectation is that you either:
All the cases listed above lead to garbage collection of the stream. The one thing you must not do is the following: Call Before this PR, in this case the stream would have been garbage collected as soon as a STOP_SENDING was received. With this PR, the PR won't be garbage collected (until you call Does this make sense? |
a28b575
to
6c0d97f
Compare
8c671ad
to
9dbdfb8
Compare
Thanks to @sukunrt for the super helpful review on this PR! |
Part of #4428.
The application now needs to somehow retrieve the error generated by receiving the STOP_SENDING frame (or, alternatively,
Close
orCancelWrite
).