Fork me on GitHub

@ikitommi thanks. For the schema thing, I was previously using reitit.ring.coercion/coerce-exceptions-middleware (, but I was able to customize the errors by replacing this with reitit.ring.middleware.exception/create-exception-middleware ( I think it's a bit unclear how these two are supposed to fit together.. For instance, I only want to expose request coercion exceptions in the response — I want everything that's not a result of a user error to result in an opaque 500 response and a detailed message in the service logs — should I be using one or the other, or both?


I would use only the latter


the first one was done first, if one only want's coercion errors to be handled, but the latter works for all exceptions


not intended to be used together, not clear in the docs


Okay, thanks 🙂 Another question: It seems like the coercion errors are only reported for the first of the body/path-params/query-params check that happens to fail, where AFAICT the checks run in the order they happen to be iterated over here: This leads to a (sort of) possibly confusing behavior that I'd like to avoid if possible. To me, it'd be preferable if I all the checks could be performed always, so that I could report all errors to the user in a consistent manner. Is this possible?


I think it would be ok to collect those all, but would require a code change. Would you like to write an issue and draft a PR out of that?


oh, it would break the current contract of error reporting.


which is a map of just one. But there could be an option to support multiple errors, via a mw option. What do you think?


(or a coercion option)


draft of "all errors with one return" message would be a good start. For 1.0.0, we can break things


Yeah, it's a bit unfortunate because the ex-data keys that end up being returned are :in and :errors.. :errors can easily be made to accommodate all errors (via something like {:body <body-errors>, :query <query-param-errors>, :path <path-param-errors>}), but I don't see how to make multiple error types work with :in.


I suppose if you fold :query/`:body`/`:path` into :errors, :in would be redundant and could be deprecated?

👍 4

By coercion option, do you mean an option in the route specification? To me a middleware option seems like it'd make more sense (it'd probably be a sensible default, too), because it'd be a bit weird to have error reporting work differently for different endpoints. Although I suppose there could be use-cases where people might prefer it (for performance reasons), so dunno.


by coercion option I meant when you define schema-coercion once in the route data with options. There the option would effect how it's thrown (fail-fast or collect all). In exception mw, you can just effect how it's rendered. I think it's ok always to collect those all and let the formatter to decide how to render


As this would be a silent breakage, it would need a major version bump, so the default should be the current one, until 1.0.0, where we could swap the default to "collect all errors" (and remove the current fail-fast impl)


issue and pr welcome!


@ikitommi so I looked into this, and it seems like what happens is that whichever of the path/route/body coercers fails first throws an exception (that's not caught by the middleware, via request-coercion-failed!) here: Do you think it's preferable to keep these exceptions (and catch, combine, and 'rethrow' them in the middleware), or to have the coercer functions return some sort of error container object instead (that can be used to build an exception)?


I would loop the results without throwing, collect error s in a seq, in any, report them all with ex, otherwise, reduce the result

👍 4