unary response has zero messages due to io.EOF for all io.EOF errors

[jipperinbham]

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-go version or commit: v0.16.2
• go version: go version go1.23.0 linux/amd64

[jhump]

@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.EOF that 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]

this is for unary RPCs using the Connect protocol, right?

Correct and sorry I wasn't more explicit with the protocol used.

[jhump]

My comment in that PR was

So while it doesn't fully resolve #774, it should help a lot.

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...