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

REST fallback does not use most fine-grained error code available when parsing errors #1634

Open
MarkDuckworth opened this issue Jul 15, 2024 · 1 comment · May be fixed by #1633
Open

REST fallback does not use most fine-grained error code available when parsing errors #1634

MarkDuckworth opened this issue Jul 15, 2024 · 1 comment · May be fixed by #1633
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.

Comments

@MarkDuckworth
Copy link

When canonical (gRPC) error codes are mapped to HTTP status codes, in some cases the mapping is lossy. Multiple canonical error codes map to one HTTP status code. For example ABORTED and ALREADY_EXISTS both map to 409. By using only the HTTP status code (409) a client would not be able to differentiate how to retry these errors.

The error response returned from Google's JSON HTTP APIs includes the gRPC error code in error.status, so this behavior can be addressed by parsing error.status and only falling back to the http status code if the grpc code is not provided.

@MarkDuckworth MarkDuckworth added priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns. labels Jul 15, 2024
@MarkDuckworth
Copy link
Author

Fix PR opened: #1633

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p2 Moderately-important priority. Fix may not be included in next release. type: bug Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Projects
None yet
1 participant