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

feat(types): Add gRPC Richer Error Model support (RetryInfo) #1095

Merged
merged 4 commits into from
Dec 1, 2022

Conversation

flemosr
Copy link
Contributor

@flemosr flemosr commented Sep 29, 2022

Motivation

The gRPC Richer Error Model is quite useful to send additional feedback to clients, and is supported by many gRPC libraries in other languages.

Solution

This PR continues the work initiated at #1068. It improves the organization of tonic-types modules, and adds support for the RetryInfo standard error message type to that crate.

Start using `mod.rs` filenames. This makes the style more consistent
across crates.
Add the code related to richer error model support to a new
`richer_error` module. This improves readability and hopefully will
make it easier to add new features to `tonic-types` in the future.
Following implementation at flemosr/tonic-richer-error.
@LucioFranco
Copy link
Member

Oh somehow this totally fell off my radar let me review this on monday! sorry about the delay.

Copy link
Member

@LucioFranco LucioFranco left a comment

Choose a reason for hiding this comment

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

LGTM overall have a few comments once those are addressed we can merge. Sorry for the delay again!

details,
};

Bytes::from(status.encode_to_vec())
Copy link
Member

Choose a reason for hiding this comment

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

Why encode to vec instead of using BytesMut + BufMut and regular encode? So that we avoid the vec round trip?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Using BytesMut indeed makes much more sense, thanks! It seems to me that using BufMut is not necessary in this case but I may be missing something.


/// Used to implement associated functions and methods on `tonic::Status`, that
/// allow the addition and extraction of standard error details.
pub trait StatusExt {
Copy link
Member

Choose a reason for hiding this comment

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

We probably want to seal this trait similar to https://docs.rs/tower-http/latest/src/tower_http/builder.rs.html#45 that way outside users can't implement it and we can add more required fn as we please without making a breaking change.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are right. I did not know this pattern, quite useful. Thanks!

Comment on lines 6 to 7
use super::super::pb;
use super::super::{FromAny, IntoAny};
Copy link
Member

Choose a reason for hiding this comment

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

Nit: I like combining these since they have a similar path.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I missed that, thanks!

Adjustments following suggestions by @LucioFranco in hyperium#1095.

Improve `gen_details_bytes`, seal `StatusExt`, adjust imports style.
@flemosr
Copy link
Contributor Author

flemosr commented Nov 20, 2022

No problem! Hopefully I addressed all comments but please let me know if you think we should make any further changes.

Copy link
Member

@LucioFranco LucioFranco left a comment

Choose a reason for hiding this comment

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

LGTM!

@LucioFranco LucioFranco merged commit 6cdb3d4 into hyperium:master Dec 1, 2022
@flemosr flemosr deleted the richer-error-split-2 branch December 4, 2022 14:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants