Skip to content

Fix GoogleRPCStatus encoding/decoding #58

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

Merged
merged 2 commits into from
Apr 9, 2025
Merged

Conversation

glbrntt
Copy link
Collaborator

@glbrntt glbrntt commented Apr 9, 2025

Motivation:

The 'rich' error model packs a google.rpc.status protobuf message into the trailing metadata of an RPC. This should just be the base64 encoded bytes of the serialzed message. At the moment this is packed within a google.protobuf.any and then added to the metadata which doesn't interop well with other languages.

Modifications:

  • Remove the indirection
  • Add methods for serializing/deserializing the RPC status wrapper

Result:

Better interop

Motivation:

The 'rich' error model packs a google.rpc.status protobuf message into
the trailing metadata of an RPC. This should just be the base64 encoded
bytes of the serialzed message. At the moment this is packed within a
google.protobuf.any and then added to the metadata which doesn't
interop well with other languages.

Modifications:

- Remove the indirection
- Add methods for serializing/deserializing the RPC status wrapper

Result:

Better interop
@glbrntt glbrntt added the 🆕 semver/minor Adds new public API. label Apr 9, 2025
@glbrntt glbrntt requested a review from gjcairo April 9, 2025 08:04
/// fields.
/// - partial: If `false` (the default), this method will check if the `Message`
/// is initialized after decoding to verify that all required fields are present.
/// If any are missing, this method throws `BinaryDecodingError`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we be making promises in the docs about the type of the error we're throwing? Can't we use typed throws instead, or omit it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. These are from the protobuf docs and we're really just wrapping the protobuf call so I think it's okay. We shouldn't use typed throws as that paints us into a corner (also, protobuf doesn't use it) if the error type does change.

@glbrntt glbrntt merged commit 5edbc18 into grpc:main Apr 9, 2025
26 of 27 checks passed
@glbrntt glbrntt deleted the error-details branch April 9, 2025 10:49
dongjoon-hyun added a commit to apache/spark-connect-swift that referenced this pull request Apr 18, 2025
…O Transport` to 1.0.3

### What changes were proposed in this pull request?

This PR aims to upgrade `gRPC Swift Protobuf` to 1.2.0 and `gRPC Swift NIO Transport` to 1.0.3.

### Why are the changes needed?

To bring the latest bug fixes.
- https://github.com/grpc/grpc-swift-protobuf/releases/tag/1.2.0
  - grpc/grpc-swift-protobuf#58
- https://github.com/grpc/grpc-swift-nio-transport/releases/tag/1.0.3

### Does this PR introduce _any_ user-facing change?

No, there is no behavior change.

### How was this patch tested?

Pass the CIs.

### Was this patch authored or co-authored using generative AI tooling?

No.

Closes #71 from dongjoon-hyun/SPARK-51846.

Authored-by: Dongjoon Hyun <[email protected]>
Signed-off-by: Dongjoon Hyun <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🆕 semver/minor Adds new public API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants