Skip to content

grpc: Implement grpc-status-details-bin rich error details#2716

Open
ejona86 wants to merge 1 commit into
grpc:masterfrom
ejona86:grpc-status-details-bin
Open

grpc: Implement grpc-status-details-bin rich error details#2716
ejona86 wants to merge 1 commit into
grpc:masterfrom
ejona86:grpc-status-details-bin

Conversation

@ejona86

@ejona86 ejona86 commented Jul 1, 2026

Copy link
Copy Markdown
Member

The existing grpc status APIs have been duplicated in grpc-protobuf, but with the addition of status payloads. The expectation is these will be removed when absl status is available. Since we now know the existing grpc status APIs will not be be converted to absl status, they have been changed to use the rust-typical Result.

StatusCodeError is redefined in grpc-protobuf rather than aliased from the grpc crate to allow a future 1:1 migration to absl status.

This is API breaking for existing status usages; grpc-protobuf now uses a different status type and the grpc crate no longer has Status/StatusOr.

This also adds a new public API grpc::StatusError::into_parts() for more efficient conversion. This could have been into_message() or message_mut(), but into_parts() seemed nicer for this struct that is unlikely to have fields added in the future.

CC @arjan-bal, @sauravzg

The existing grpc status APIs have been duplicated in grpc-protobuf, but
with the addition of status payloads.  The expectation is these will be
removed when absl status is available.  Since we now know the existing
grpc status APIs will _not_ be be converted to absl status, they have
been changed to use the rust-typical Result.

StatusCodeError is redefined in grpc-protobuf rather than aliased from
the grpc crate to allow a future 1:1 migration to absl status.

This is API breaking for existing status usages; grpc-protobuf now uses
a different status type and the grpc crate no longer has
Status/StatusOr.

This also adds a new public API grpc::StatusError::into_parts() for more
efficient conversion. This could have been into_message() or
message_mut(), but into_parts() seemed nicer for this struct that is
unlikely to have fields added in the future.
@ejona86 ejona86 requested a review from dfawley July 1, 2026 23:38
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.

1 participant