cloudflare / cloudflare/quiche

Connection::stream_send() reports Err::Done for finished streams

Open
#1,695 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
11.8k
Forks
1.1k
Avg merge
21h 9m
Merged PRs (30d)
6

Description

This case occurs with streams closed with STOP_SENDING, then a fin bit being received too, then the data being read via `Connection::stream_recv()`.

In high-level terms:
```
server opens stream - sends some data
client reads some data and writes data
server reads that data, sends STOP_SENDING, and writes some data, then sends the fin bit in a separate empty message of length 0
client sees stream as readable, then reads the data
client tries to write some data ... gets Err::Done from stream_send().
```

As far as I gathered from the documentation, `Err::Done` is supposed to be returned when no data could be written because of no capacity and `Err::StreamStopped` returned when the stream has been closed by the peer.

In this specific case though, the stream seems to already have been freed by quiche, thus `StreamMap::get_or_create()` returns `Err::Done`, which `Connection::stream_send()` simply forwards.

I would expect an `Err::StreamStopped`, or at least an `Err::InvalidStreamState` (signaling that a stream with that id could not be created, in that case, obviously, because the stream id is not matching what's allowed for the client/server).

Currently I'm working around it with an extra check of `Connection::stream_writable()` for `Err::InvalidStreamState` whenever `Err::Done` is reported, but that seems unnecessary/wrong to me, why would that be needed?

In case this is the expected behaviour though, I would like to ask for a note in the documentation to check stream_writable() explicitly if `Err::Done` is returned.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.