-
-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple spec support breaks if validateResponses: true #881
Comments
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
The second spec contains an extra call and extra schema in the components
Actual behavior
Error: can't resolve reference #/components/schemas/Products2 from id #
Expected behavior
Each spec should be validated against its own schemas
Examples and context
v1.yaml
v2.yaml
index.js
simple test from curl
The text was updated successfully, but these errors were encountered: