You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for the report! This is probably a bug in the ReadExact::poll implementation that arises when the finish notification is delivered separately from other data, or perhaps whenever multiple operations are required. The math is a bit difficult to follow so it's not immediately obvious to me what the bug is, but that difficulty makes it highly suspect and indicates a need for revision regardless.
Maybe I am missing something, but:
Client
The client opens a unidirectional stream, it writes 5 bytes, and after 1 second idle it
FIN
the stream.Server
The server accepts the unidirectional stream, it tries to read 1024 bytes.
Expected behavior:
On the server side,
read_exact
should fail withFinishedEarly(5)
, as it read theFIN
bit after 5 bytes (without filling the entirebuffer
).Current behavior (commit:
393b617ef1c76c7a6f0dad33905466fb266580bd
)On the server side,
read_exact
instead fails withFinishedEarly(0)
. Note the0
bytes are read.Additional Notes
It works as expected if
tokio::time::sleep
is removed.Attached, a dirty-modified version of
quinn/examples/(client|server).rs
that I've used to reproduce the above scenarioexample_finish_early.txt
The text was updated successfully, but these errors were encountered: