Not sure if I am missing something, but I don't manage to get a 400 with the syntax we are using all around our REST API code. return $c->render( status => 400, openapi => { error => "this is an error" } ); I am getting a 500 with, in Koha logs: [{"message":"Missing property.","path":"\/body\/errors"}] So yes, it is working with: return $c->render( status => 400, openapi => { errors => [ {message => 'this is an error'}] } ); But it's not at all what we are doing in our REST API module.
We narrowed this one down.. it's the patrons search (GET) we're looking at and it appears we're missing our local '400' definition in the spec file /paths/patrons.yaml
Shouldn't we add the different errors for each route?
I do however find it really weird still that you can define more than one definition for the same response status on the endpoint... i.e. the internal 400 definitions for the validator software and then our own one for our own errors. I would have expected our definition to take precedence over the internal one and thus need it to be a superset of the built-in one. Interesting.
(In reply to Martin Renvoize from comment #3) > I do however find it really weird still that you can define more than one > definition for the same response status on the endpoint... > > i.e. the internal 400 definitions for the validator software and then our > own one for our own errors. > > I would have expected our definition to take precedence over the internal > one and thus need it to be a superset of the built-in one. > > Interesting. Doesn't our definition just overload the default/internal one? It used to return a 500 because it wasn't considered a valid response in the spec, which I find correct.
Ok, tested myself, this is some Mojolicious::Plugin::OpenAPI bug. Reported it: https://github.com/jhthorsen/mojolicious-plugin-openapi/issues/237
(In reply to Tomás Cohen Arazi from comment #5) > Ok, tested myself, this is some Mojolicious::Plugin::OpenAPI bug. > > Reported it: > https://github.com/jhthorsen/mojolicious-plugin-openapi/issues/237 I see that the bug has been closed - anything we can do here now?