Repository navigation
unary response has zero messages due to io.EOF for all io.EOF errors #774
Description
Describe the bug
After updating our dependency from 1.15.0 to 1.16.2, we started to see the error unary response has zero messages returned where we previously used to see io.EOF. #712 appears to have caused the behavioral change to return connect.CodeUnimplemented instead of io.EOF for all cases of io.EOF which can come from general network/transport errors and nothing to do with the gRPC doc linked in the PR. We were relying on io.EOF in a client interceptor to automatically retry requests since we can occasionally see the error due to network flakiness and have since updated to check for the connect.Unimplemented code and error now.
To Reproduce
I couldn't really come up with a great way to provide a reproducible test for this but am happy to do so if it's a blocker.
Environment (please complete the following information):
connect-goversion or commit:v0.16.2go version:go version go1.23.0 linux/amd64
Activity
jhump commentedon Sep 4, 2024
@jipperinbham, this is for unary RPCs using the Connect protocol, right?
@Alfus, pretty sure this is the same issue you encountered and mentioned to me.
We need a way to distinguish when the
io.EOFthat the framework observes is caused from an actual EOF on the socket (i.e. an unexpected network hangup) vs. when reaching the normal end of the response body. (There are cases in HTTP 1 where it may be impossible to tell, in which case we should assume the former, not the latter.) When the EOF is the former, we should wrap it with an RPC "unavailable" error instead of incorrectly interpreting it as a cardinality violation and replacing it with "unimplemented".jipperinbham commentedon Sep 4, 2024
Correct and sorry I wasn't more explicit with the protocol used.
jhump commentedon Sep 17, 2024
My comment in that PR was
And yet GitHub decided to auto-close this issue when that PR was merged 😞.
Since it's not fully resolved, I want this issue left open. So re-opening...