Cardinality violations should use error code “unimplemented”

[jhump]

The gRPC docs for error codes state that both client and server should use the unimplemented code for cardinality violations. See table at the bottom of this doc (you can search for “cardinality violation” in the doc): https://grpc.github.io/grpc/core/md_doc_statuscodes.html.

A cardinality violation is when a stream contains an incorrect number of messages. Specifically, when a response stream for a unary or client-stream RPC contains zero messages with an OK status or more than one message; or when a request stream for a unary or server-stream RPC contains zero or more than one messages.

The server in this repo conforms to the documented behavior, but the client does not.

1. For unary and client-stream RPCs, if no response messages are present in the response, only an “OK” status, the client reports an internal error (with a message of “No message received”) instead of unimplemented.
2. For unary and client-stream RPCs, if a second response message is erroneously sent by the server before the trailers/status, the operation appears to hang indefinitely (!!). A metadata event is triggered, but nothing else — no callback, no error event, no status event, and no end event.

[ejona86]

For the Java issue I mentioned this change to the spec was made without any real notification/discussion. So we may want to re-consider the spec in this case. grpc/grpc-java#11247 (comment)

[ejona86]

To be clear: we should definitely fix the hang, and we don't need agreement on the status code before doing so.

[murgatroid99]

This is fixed in version 1.10.10.