Closed BiagioFesta closed 4 weeks ago
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 scenario example_finish_early.txt