Middleware Defined Errors

[rrmesquita]

I'm pretty new to this package, so let me know if I'm missing something.

When I .use() a middleware that predefines its errors, the errored response returns with defined set as false. AFAIK, this is key when handling the errors because of isDefinedError, right?

Is that intended, or should I open an issue for this?

[dosubot[bot]]

Hi @rrmesquita! I'm Dosu and I’m helping the orpc team.

You're right—middleware-defined errors should have defined: true if you construct them using the error constructors provided in the middleware's options.errors map. This is what allows isDefinedError to reliably distinguish between known (type-safe) and unknown errors. If you're seeing defined: false for errors you expect to be defined, it's likely that the error wasn't created using the registered constructor, or there's a bug in how errors are normalized or propagated downstream. This isn't the intended behavior—middleware errors registered via .use() and thrown with the provided constructors should be marked as defined. If double-checking your error construction doesn't resolve it, this may warrant further investigation or a minimal reproduction for maintainers to look at. You can see the relevant implementation details in the ORPCError class and server error handling.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[unnoq]

This is expected behavior because procedures do not inherit errors from middleware. When you throw a defined error from middleware, oRPC attempts to validate it and sets the result to false if no corresponding error is defined in the procedure.

This was also a feature request, but after multiple attempts, I decided not to support it. oRPC middleware can become overly complicated, and I want type-safe errors to remain optional without affecting the dx at all.

[rrmesquita]

Got it. Thanks for answering and for making this awesome lib — I'm really enjoying using it.