Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cardinality violations should use error code “unimplemented” #1429

Open
jhump opened this issue May 30, 2024 · 2 comments
Open

Cardinality violations should use error code “unimplemented” #1429

jhump opened this issue May 30, 2024 · 2 comments

Comments

@jhump
Copy link
Member

jhump commented May 30, 2024

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 response stream contains an incorrect number of messages. Specifically, when the response stream for a unary RPC contains zero messages with an OK status or more than one message. (The same goes for client-stream RPCs, which also expect a unary response, but this package does not support client-streaming.)

The client in this package returns an unknown error in this situation instead of unimplemented.

@ejona86
Copy link
Member

ejona86 commented May 31, 2024

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)

@sampajano
Copy link
Collaborator

Thanks for reporting the issue, and thanks @ejona86 for clarifying!

I'm happy to make the changes on the grpc-web side once we reached conclusion on how other languages would be aligned (or the spec would be updated), per grpc/grpc-java#11247 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants