Revert: Status: FromError: Return Entire Error Message Text For Wrapped Errors

by ADMIN 79 views

Revert: status: FromError: return entire error message text for wrapped errors

Use case(s) - what problem will this feature solve?

The current implementation of status.FromError in the gRPC Go library has two major issues that need to be addressed. The first issue is that the original status message is changed when using errors.Join to wrap an error. This results in an unexpected and inconsistent behavior, where the original status message is modified and includes the rendered status string. The second issue is that the behavior is inconsistent when retrieving the original status from an error that implements the grpcstatus interface.

Problem Statement

The current implementation of status.FromError has two main problems:

  1. Original status message changed with errors.Join: When using errors.Join to wrap an error, the original status message is modified and includes the rendered status string. This results in an unexpected and inconsistent behavior.
  2. Inconsistent behavior: The behavior of status.FromError is inconsistent when retrieving the original status from an error that implements the grpcstatus interface. It returns a modified status from an error that also implements the grpcstatus interface but is wrapped.

Example Use Case

To illustrate the problem, let's consider the following code:

package main

import (
	"errors"
	"log/slog"

	"google.golang.org/grpc/status"
)

func main() {
	stats := status.New(400, "status error")
	statusErr := stats.Err()
	wrappedErr := errors.Join(statusErr, errors.New("wrapper"))

	statsFromErr, _ := status.FromError(statusErr)
	statsFromWrappedErr, _ := status.FromError(wrappedErr)

	slog.Info("stats", "msg", stats.Message())
	slog.Info("stats from error", "msg", statsFromErr.Message())
	slog.Info("stats from wrapped error", "msg", statsFromWrappedErr.Message())
}

The output of this code is:

INFO stats msg="status error"
INFO stats from error msg="status error"
INFO stats from wrapped error msg="rpc error: code = Code(400) desc = status error\nwrapper"

As you can see, the original status message is modified and includes the rendered status string when using errors.Join to wrap an error.

Proposed Solution

To solve these issues, we propose to revert the changes made in #6150. This will ensure that the original status message is not modified when using errors.Join to wrap an error, and the behavior of status.FromError is consistent when retrieving the original status from an error that implements the grpcstatus interface.

Additional Context

We are happy to create a PR for this change. If you have any feedback or suggestions, please let us know.

Benefits of the Proposed Solution

The proposed solution has several benefits:

  1. Consistent behavior: The behavior of status.FromError will be consistent when retrieving the original status from an error that implements the grpcstatus interface.
  2. Original status message preserved: The original status message will not be modified when using errors.Join to wrap an error.
  3. Improved code quality: The code will be more predictable and easier to maintain.

Implementation Details

To implement the proposed, we will revert the changes made in #6150. This will involve removing the code that modifies the original status message when using errors.Join to wrap an error, and ensuring that the behavior of status.FromError is consistent when retrieving the original status from an error that implements the grpcstatus interface.

Testing

We will test the proposed solution thoroughly to ensure that it works as expected. This will involve writing unit tests and integration tests to cover all possible scenarios.

Conclusion

In conclusion, the proposed solution will address the two major issues with the current implementation of status.FromError. It will ensure that the original status message is not modified when using errors.Join to wrap an error, and the behavior of status.FromError is consistent when retrieving the original status from an error that implements the grpcstatus interface. We believe that this solution will improve the code quality and make it more predictable and easier to maintain.
Q&A: Revert: status: FromError: return entire error message text for wrapped errors

Q: What is the current issue with status.FromError?

A: The current implementation of status.FromError has two major issues. The first issue is that the original status message is changed when using errors.Join to wrap an error. This results in an unexpected and inconsistent behavior, where the original status message is modified and includes the rendered status string. The second issue is that the behavior is inconsistent when retrieving the original status from an error that implements the grpcstatus interface.

Q: What is the problem with the original status message being modified?

A: The original status message being modified is a problem because it results in an unexpected and inconsistent behavior. When using errors.Join to wrap an error, the original status message is modified and includes the rendered status string. This makes it difficult to predict and maintain the code.

Q: What is the problem with the inconsistent behavior of status.FromError?

A: The inconsistent behavior of status.FromError is a problem because it makes it difficult to predict and maintain the code. When retrieving the original status from an error that implements the grpcstatus interface, the behavior of status.FromError is inconsistent. It returns a modified status from an error that also implements the grpcstatus interface but is wrapped.

Q: How will the proposed solution address these issues?

A: The proposed solution will address these issues by reverting the changes made in #6150. This will ensure that the original status message is not modified when using errors.Join to wrap an error, and the behavior of status.FromError is consistent when retrieving the original status from an error that implements the grpcstatus interface.

Q: What are the benefits of the proposed solution?

A: The proposed solution has several benefits. It will ensure that the behavior of status.FromError is consistent when retrieving the original status from an error that implements the grpcstatus interface. It will also preserve the original status message when using errors.Join to wrap an error. Additionally, the code will be more predictable and easier to maintain.

Q: How will the proposed solution be implemented?

A: The proposed solution will be implemented by reverting the changes made in #6150. This will involve removing the code that modifies the original status message when using errors.Join to wrap an error, and ensuring that the behavior of status.FromError is consistent when retrieving the original status from an error that implements the grpcstatus interface.

Q: What testing will be done to ensure the proposed solution works as expected?

A: We will test the proposed solution thoroughly to ensure that it works as expected. This will involve writing unit tests and integration tests to cover all possible scenarios.

Q: What is the expected outcome of the proposed solution?

A: The expected outcome of the proposed solution is that the behavior of status.FromError will be consistent when retrieving the original status from an error that implements the grpcstatus interface. The original status message will also be preserved when using errors.Join to wrap an error. The code will be more predictable and easier to maintain.

Q: Who will responsible for implementing the proposed solution?

A: We will be responsible for implementing the proposed solution. We will work closely with the development team to ensure that the solution is implemented correctly and meets the requirements.

Q: What is the timeline for implementing the proposed solution?

A: We will work with the development team to determine the timeline for implementing the proposed solution. We will ensure that the solution is implemented as soon as possible to minimize the impact on the codebase.

Q: How will the proposed solution be reviewed and validated?

A: The proposed solution will be reviewed and validated by the development team and other stakeholders. We will ensure that the solution meets the requirements and is implemented correctly.