Need more control over error handling
This is coming up as a result of some security testing against our API where we discovered that malformed URIs result in 500 errors (which in turn hit our error reporter).
We believe that these errors should be 400x errors, but it isn't entirely clear how to accomplish this.
In this particular case, the URIError is generated by tRPC itself, not our procedures, which means it's not as easy as wrapping the procedure and throwing the appropriate tRPC error instance.
Instead, the error bubbles up from tRPC internals and then gets handled by
getTRPCErrorFromUnknown, where I have no control over using a BAD_REQUEST error.
Ideally, we would be able to define the behavior of getTrpcErrorFromUnknown and implement logic that checks instanceof URIError and creates a BAD_REQUEST error rather than an INTERNAL_SERVER_ERROR.4 Replies
Adding to this, we don't like the default behavior of
getTRPCErrorFromUnknown which will create a TRPCError using the cause message. This means that any uncaught error from deep in our service would bubble up to the end consumer.
In particular, we found that there were cases where db errors were being pushed to the client inside of the error message payload. Ideally, we would proxy through errors in dev, put provide general errors messages in production-like environments.we discovered that malformed URIs result in 500 errors (which in turn hit our error reporter).that sounds like a bug, open an issue 🙏
Ideally, we would be able to define the behavior of getTrpcErrorFromUnknown and implement logic that checks instanceof URIError and creates a BAD_REQUEST error rather than an INTERNAL_SERVER_ERROR.that might be a good fix! legit bugs usually don't stay open for more than a few days or a week
Ok—I thought it might be easier to flesh out the details via Discord chat, but I'm happy to open an issue and discuss solutions in GH. Thanks!
did you get to the root of this?