Open fpolowood opened 8 months ago
I think the problem stems from both validators mung'ing the request.json method which chains validation which is probably not what you want.
ResponseValidator (from metadataMiddleware) will hook the res.json method. First, it does this for v1 and then for v2. Meaning when res.json gets called in the route, it first get the v2 hook for validation which then calls the v1 hook for validation before calling the original. Inefficient, but OK.
metadataMiddleware will set req.openapi to matching schema. In this case, it will set it to the v2 schema.
Then the validators get called via res.json. The v2 ResponseValidator is called, builds/caches the validator and all is good. Then it delegates to the v1 ResponseValidator. This has has ajvBody set up for the v1 apidoc.
However, buildValidators builds contentTypeSchemas from the res.openapi schema (v2!) and then calls ajvBody to compile one of these schemas. Since ajvBody is bound to the v1 schema, this will raise the exception.
I'm thinking the solution is to not double hook res.json. Hook it ONLY if the request has openapi set to the matching apidoc.
An alternative would be to have the validate() lambda (inside the mung call) to check that req.openapi somehow matches the apidoc associated with the schema.
@fpolowood Please verify on v5.1.6
Describe the bug If I turn on validateResponses: true when using multiple specs, it seems to use the first spec for the definition of the components
To Reproduce
Actual behavior
Expected behavior Each spec should be validated against its own schemas
Examples and context v1.yaml
v2.yaml
index.js
simple test from curl