[grpc_error] enable error_flatten experiment in OSS#41471
Closed
markdroth wants to merge 5 commits into
Closed
Conversation
murgatroid99
approved these changes
Jan 23, 2026
Member
Author
|
It looks like there are a bunch of test failures here. Before I rolled out the experiment internally, I verified that all of our tests passed with it enabled, but I guess there have been some changes since then that introduced tests that are breaking now. Converting this to a draft while I fix those tests. |
Member
Author
|
Most of the failures seem to have gone away on their own by the time I got back to this. The one remaining failure was fixed in #41940. |
asheshvidyut
pushed a commit
to asheshvidyut/grpc
that referenced
this pull request
Apr 8, 2026
This enables a change that involves using `absl::Status` internally to represent RPC statuses. This will cause a few small behavior changes that may be visible to applications: - If a server returns status code OK, any associated status message will be dropped instead of being passed through as it used to be. This matches the behavior of `absl::Status`, which ignores the message if the code is OK. - If a server returns a status code that is not one of the [canonical codes](https://github.com/grpc/grpc/blob/master/include/grpc/status.h), gRPC will now convert those codes to `UNKNOWN` instead of passing them through. Again, this matches the behavior of `absl::Status`. - As part of this change, status messages generated internally by gRPC may be different than they were before (e.g., instead of "Deadline Exceeded", you may see "Stream removed (Deadline Exceeded)"). Note that gRPC has never guaranteed that the content of internally generated status messages are stable, so this change should not break anything that was not relying on unstable behavior to begin with. - It is conceivably possible that there may be some rare cases in which we may change which status code we return for a particular error from inside of gRPC. The most likely situation in which this could happen is an error where we previously returned an `UNKNOWN` status, where we might now return a different (probably better) status code instead. I do not know of any cases where this has actually happened, but I cannot conclusively prove that it can't happen, so I mention it here just in the spirit of full transparency. See grpc#38874 for the implementation. b/416058825 Closes grpc#41471 COPYBARA_INTEGRATE_REVIEW=grpc#41471 from markdroth:error_flatten_enable 1c52ef0 PiperOrigin-RevId: 891754308
asheshvidyut
pushed a commit
to a-detiste/grpc
that referenced
this pull request
Jun 10, 2026
This enables a change that involves using `absl::Status` internally to represent RPC statuses. This will cause a few small behavior changes that may be visible to applications: - If a server returns status code OK, any associated status message will be dropped instead of being passed through as it used to be. This matches the behavior of `absl::Status`, which ignores the message if the code is OK. - If a server returns a status code that is not one of the [canonical codes](https://github.com/grpc/grpc/blob/master/include/grpc/status.h), gRPC will now convert those codes to `UNKNOWN` instead of passing them through. Again, this matches the behavior of `absl::Status`. - As part of this change, status messages generated internally by gRPC may be different than they were before (e.g., instead of "Deadline Exceeded", you may see "Stream removed (Deadline Exceeded)"). Note that gRPC has never guaranteed that the content of internally generated status messages are stable, so this change should not break anything that was not relying on unstable behavior to begin with. - It is conceivably possible that there may be some rare cases in which we may change which status code we return for a particular error from inside of gRPC. The most likely situation in which this could happen is an error where we previously returned an `UNKNOWN` status, where we might now return a different (probably better) status code instead. I do not know of any cases where this has actually happened, but I cannot conclusively prove that it can't happen, so I mention it here just in the spirit of full transparency. See grpc#38874 for the implementation. b/416058825 Closes grpc#41471 COPYBARA_INTEGRATE_REVIEW=grpc#41471 from markdroth:error_flatten_enable 1c52ef0 PiperOrigin-RevId: 891754308
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This enables a change that involves using
absl::Statusinternally to represent RPC statuses. This will cause a few small behavior changes that may be visible to applications:absl::Status, which ignores the message if the code is OK.UNKNOWNinstead of passing them through. Again, this matches the behavior ofabsl::Status.UNKNOWNstatus, where we might now return a different (probably better) status code instead. I do not know of any cases where this has actually happened, but I cannot conclusively prove that it can't happen, so I mention it here just in the spirit of full transparency.See #38874 for the implementation.
b/416058825