-
Notifications
You must be signed in to change notification settings - Fork 531
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
Correctly resolve externalRefs that point to the root path #1963
base: master
Are you sure you want to change the base?
Conversation
Upon further inspection, this only fixes a portion of the failing cases. I've observed two so far--what I'll call "A-B-A," where schemas in B reference schemas in A, and A is the top-level document, but I've discovered a new one--what I'll call "A-B-C-B," where schemas in A reference schemas in B, and schemas in C reference schemas in B. An example schema is given below (not tested yet): foo.yaml
bar.yaml:
baz.yaml:
|
4c79270
to
5049653
Compare
Previously, if OpenAPI v3 document A loads document B, and B refers to schemas in document A, swagger-parser would not resolve references to schemas in A as internal refs, even though they refer to the root OpenAPI v3 document (document A). This would result in the creation of duplicate schemas for those schemas in document A. Now, we resolve these "external" refs as internal refs, preventing the duplication of these schemas by the ExternalRefProcessor.
5049653
to
471a6c9
Compare
I believe this fixes all the issues that I have observed. I have not been able to reproduce the "A-B-C-B" case since I originally saw it, so it's entirely possible that was a fluke. I believe this PR is ready for review/merge. |
Previously, if OpenAPI v3 document A loads document B, and B refers to schemas in document A, swagger-parser would not resolve references to schemas in A as internal refs, even though they refer to the root OpenAPI v3 document (document A). This would result in the creation of duplicate schemas for those schemas in document A. Now, we resolve these "external" refs as internal refs, preventing the duplication of these schemas by the ExternalRefProcessor.
This fixes issue #1961.