You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 19, 2024. It is now read-only.
There is an ability to customize the message for errors which don't throw from input validation, but no ability to modify the body otherwise.
I'm trying to convert an existing express-only server to use tRPC with trpc-openapi so we get the TypeScript client, autogen'd docs, etc.
The problem I'm running into is that we currently return a property reason in the error response body, and unfortunately there is a requirement to maintain this behavior.
Right now this is possible, but it's nasty.
For the onError argument I'm hijacking the NodeHTTPResponseend function:
I'm wondering if you would be open to PRs to enable more error customization. The change would probably involve making onError return a body and status code. I'm not sure how this would affect the openApi spec generation, or how exactly it would interact with responseMeta, but I'm sure we could figure out details.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
trpc-openapi
is opinionated about the body of error responses:There is an ability to customize the message for errors which don't throw from input validation, but no ability to modify the body otherwise.
I'm trying to convert an existing express-only server to use tRPC with
trpc-openapi
so we get the TypeScript client, autogen'd docs, etc.The problem I'm running into is that we currently return a property
reason
in the error response body, and unfortunately there is a requirement to maintain this behavior.Right now this is possible, but it's nasty.
For the
onError
argument I'm hijacking the NodeHTTPResponseend
function:I'm wondering if you would be open to PRs to enable more error customization. The change would probably involve making
onError
return a body and status code. I'm not sure how this would affect the openApi spec generation, or how exactly it would interact withresponseMeta
, but I'm sure we could figure out details.The text was updated successfully, but these errors were encountered: