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.
This commit adds a new `CodeGenBuilder` that replaces the
client/server generate fn with a builder stlye that allows
adding config items in an non-breaking way. This also deprecates
both of the client/server generate fn in favor of the builder ones.
* add `Result<T>` type alias for `std::result::Result<T, tonic::Status>`
* Allow user to override the error type
Co-authored-by: David Pedersen <david.pdrsn@gmail.com>
* add rustdoc for `tonic::Result`
* cargo fmt
Co-authored-by: David Pedersen <david.pdrsn@gmail.com>
* types: add tonic as dependency, add error_details.proto
* types: add BadRequest support from flemosr/tonic-richer-error
* types: adjust code following suggestions
Adjustments following suggestions by @LucioFranco in https://github.com/hyperium/tonic/pull/1068.
Adjust style, remove unecessary prints, avoid glob imports, apply
`non_exhaustive` to `ErrorDetails` and `ErrorDetail`, avoid pub
fields in `ErrorDetails`, adjust
`WithErrorDetails::with_error_details_vec` args, add
`gen_details_bytes`.
* types: add generated protobuf code
As suggested by @LucioFranco in https://github.com/hyperium/tonic/pull/1068#discussion_r956117520.
This avoids the need for consumers to have `protoc` in their path.
Implemented following changes in https://github.com/hyperium/tonic/pull/1065.
* types: add custom metadata support
This allows consumers to provide custom metadata when creating a
`Status` with error details.
* types: adjust code following suggestions
Adjustments following suggestions by @LucioFranco in https://github.com/hyperium/tonic/pull/1068.
Move `error_details_vec` mod into `error_details` mod, adjust doc
comments, rename `WithErrorDetails` trait to `StatusExt`.
* tonic-health: commit generated code rather than generating at build time
This saves users from needing protoc available on their path if they're not
generating other tonic code at build time, either.
The generated modules can be regenerated by enabling the `gen-proto`
feature, which will trigger the relevant part of the build script.
* Check generated code for tonic-health matches in CI
* Use bootstrap test to generate/check validity of generated code
As suggested by @LucioFranco in https://github.com/hyperium/tonic/pull/1065\#discussion_r951580189.
This avoids the need for a feature which would show
up in docs.rs, and achieves the same goals via CI.
tottoto