Usage of tokio::fs/io in client stream handler function seems to prohibit client stream error propagation
Bug Report
Version
tokio = { version = "1.6.1", features = ["macros", "rt-multi-thread", "io-std", "io-util", "fs", "time"] }
tokio-stream = "0.1.6"
tonic = { version = "0.4.3", features = ["tls"] }
prost = "0.7.0"
prost-types = "0.7.0"
Platform
macOS 11.5.1 amd64
Description
I have a function handling the parsing and writing of binary assets contained with proto messages to disk, called from the client stream handler message loop. In the asset writing function I make use of tokio::fs/io for creating directories, writing and flushing to disk.
However, when the stream was dropped by the client, instead of the stream.message().await returning an Err the gRPC function handler seemed to simply stop as far as I could tell. No panics, just the following line posted to stdout:
DEBUG hyper::proto::h2::server] stream error: connection error: broken pipe
When printing to stdout during the asset write function the execution always stopped around awaiting a tokio::fs/io call. I could not find anything or produce any theory what is going on, I ultimately did manage to resolve it by switching to the regular std::fs/io calls.
When the stream drops now, the following log message gets printed and I do actually get an Err on the stream.message().await function.
[2021-08-18T19:25:59Z DEBUG tonic::codec::decode] decoder inner stream error: Status { code: Unknown, message: "h2 protocol error: broken pipe" }
Sorry if this report is a bit vague but after several days I was not able to get any insight into why this is happening, hopefully this rings a bell somewhere.
Do you by chance have a simple reproduction of the issue?