Repository navigation
quic: StopSending callback #63657
Description
Activity
No, it is a problem for StopSending. But only if you need low level stream operations.
@syedahmedx3
Your answer confuses webstreams (stream.readableis not a thing for QuicStream) with the new QuicStream api.- added a commit that references this issue
on Jul 8, 2026 - added a commit that references this issue
on Jul 21, 2026 I have closed the wrong issue, I confused with another...... #64237
- added a commit that references this issue
on Jul 29, 2026 Please reopen. This issue is about receiving stopSending and not sending. I know I was the first to confuse it.
@martenrichter #64710 is now merged, does that fix the stopSending behaviour that was causing you issues? If not can you describe more what's not working here right now?
If we have a separate callback for receiving stopsending and resetstream, that is all the issue is about.
Yes, we have separate
onresetandonstopsendingcallbacks on streams, and AFAICT they now both fire when as expected when an inbound reset/stop_sending frame is received.- added a commit that references this issue
on Aug 6, 2026
The docs for
QuicStream'sonresetcallback says:1.) How can the receiver determine, if it is a RESET_STREAM frame or a STOP_SENDING frame. This is actually a big difference. So do we need a separate
onstopsending? Or is it possible to have a property to determine this?Or may be one sees it in the iterable?
2.) It does not look as if it is invoked for a STOP_SENDING frame, see:
node/src/quic/streams.cc
Line 1787 in 30a7e28
it is just interacting with the stream.
@jasnell I may discover, that this is actually not a problem if one iterates the stream, what I am not sure yet,