Deal with HTTP status other than 200

[edsko]

The spec says:

Implementations should expect broken deployments to send non-200 HTTP status codes in responses as well as a variety of non-GRPC content-types and to omit Status & Status-Message. Implementations must synthesize a Status & Status-Message to propagate to the application layer when this occurs.

We don't do this yet.

[domenkozar]

I get the following back:

 SomeExceptionWrapper (STMException [("atomically",SrcLoc {srcLocPackage = "grapesy-0.1.0-KFclJYWAZ3d94upf4VowEP", srcLocModule = "Network.GRPC.Util.Thread", srcLocFile = "src/Network/GRPC/Util/Thread.hs", srcLocStartLine = 203, srcLocStartCol = 7, srcLocEndLine = 203, srcLocEndCol = 17}),("withThreadInterface",SrcLoc {srcLocPackage = "grapesy-0.1.0-KFclJYWAZ3d94upf4VowEP", srcLocModule = "Network.GRPC.Util.Session.Channel", srcLocFile = "src/Network/GRPC/Util/Session/Channel.hs", srcLocStartLine = 339, srcLocStartCol = 5, srcLocEndLine = 339, srcLocEndCol = 24}),("recv",SrcLoc {srcLocPackage = "grapesy-0.1.0-KFclJYWAZ3d94upf4VowEP", srcLocModule = "Network.GRPC.Client.Call", srcLocFile = "src/Network/GRPC/Client/Call.hs", srcLocStartLine = 131, srcLocStartCol = 32, srcLocEndLine = 131, srcLocEndCol = 44})] (SomeExceptionWrapper (ThreadInterfaceUnavailable {threadInterfaceCallStack = [("withThreadInterface",SrcLoc {srcLocPackage = "grapesy-0.1.0-KFclJYWAZ3d94upf4VowEP", srcLocModule = "Network.GRPC.Util.Session.Channel", srcLocFile = "src/Network/GRPC/Util/Session/Channel.hs", srcLocStartLine = 339, srcLocStartCol = 5, srcLocEndLine = 339, srcLocEndCol = 24}),("recv",SrcLoc {srcLocPackage = "grapesy-0.1.0-KFclJYWAZ3d94upf4VowEP", srcLocModule = "Network.GRPC.Client.Call", srcLocFile = "src/Network/GRPC/Client/Call.hs", srcLocStartLine = 131, srcLocStartCol = 32, srcLocEndLine = 131, srcLocEndCol = 44})], threadInterfaceException = ResponseInvalidStatus (Status {statusCode = 404, statusMessage = "Not Found"})})))

It would be great if the response and request were included to be able to understand what's happening.

[edsko]

This issue is not about connectivity issues, but about non-compliant gRPC implementations that use HTTP error codes instead of gRPC error codes to indicate problems (gRPC problems are meant to be indicated with a HTTP error of 200 and then a non-zero grpc-status). The 404/not found in your message suggests it's not able to connect to the remote server at all? Not sure what kind of request/response you're hoping to see; in particular, request, response in gRPC terms (the messages sent to and from the server) have not yet happened at the connecting stage.

[edsko]

In response to @domenkozar 's comment above: as I mentioned previously, grapesy now includes the full response body in case of server errors. As of #197, a 404 Not Found from the server will now result in a GrpcUnimplemented exception; I have added a test in #207 to ensure that we still include the response body in this gRPC exception.

[edsko]

All aspects of this ticket I think are now working and tested. Also verified that the few changes we made did not break the interop tests. Closing!