Plans to support "Richer error model"?

[kevinmichaelchen]

Hello 👋🏼 This is an excellent library that seems to do the trick for my team.

I was wondering: Are there plans to support the "richer error model" discussed here?

For context: The official gRPC error model is limited, since it only supports a status code and a string. Google has developed a standard for clients to consume details about the error:

• status.proto
• error_details.proto

[aikoven]

Hey! Yes, we are absolutely planning to support it, but we're still figuring out the best API for this feature.

Some thoughts:

• As far as I understand, the rich error model is not limited by the messages defined in error_details.proto, and users can provide custom details messages. This means that we need the full support for google.protobuf.Any mechanics, i.e. to be able to find an arbitrary type by its fully-qualified name. This is already possible with ts-proto's Type Registry feature, but it will be harder to implement for google-protobuf. I'm fine with only supporting ts-proto though. There's also an option to only support messages defined in error_details.proto.
• We should probably have this feature in a separate package, instead of baking it right into the core. The ServerError and ClientError live in nice-grpc-common package which is intended to be very stable, and it is risky to add extra fields to these error classes.
• I think it would be best to implement as server and client middleware, plus extended server and client error classes which inherit from ServerError and ClientError. The server middleware catches extended server error and adds error details to the trailer. The client middleware intercepts the trailer and throws extended client error.

[kevinmichaelchen]

There's also an option to only support messages defined in error_details.proto.

I think this could be a good initial option since there is a lot of flexibility in error_details. I think my team would get a lot of mileage from those alone.

[aikoven]

Just published a new package [email protected]. Its API in a very early experimental phase, so any feedback is welcome!