-
Notifications
You must be signed in to change notification settings - Fork 937
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
Default OpenAPI Version from RootContext overwrites OpenAPI Version from OpenApi Property #1643
Comments
Good analysis. This looks like it really is a regressoon. The version is a pain as it is a classic hen/egg problem. Code might need/access it before the I think maybe explicitly setting it in the context is wrong and there should be an accessor method instead that knows to use a fallback. That way there is a safe way to access the best guess at the time while allowing to set the most specific one when possible. Thanks for bringing this up - been annoying me for quite some time :) |
Could you try #1644 - that should work for you. |
Just tried it, the branch works. 😄 Thanks for looking into this so fast. I have a workaround where I pair the APIs with the OpenAPI version and pass it to the generator for each API but it's cleaner without the redundancy. :) My 2 cents on this (even though no one asked 😆 ): While I'm not that familiar with the code but it seems like the root context is jsut there for the version and the logger? I think the logger should just live in the generator and then passed down. For the version: Might be worth to find the OpenApi Attribute after the sources are scanned and fetch the version from there. Then you probably could get rid of the root context entirely? Another thing would be to do some sorting after the sources are scanned but before the whole analysis is run. Then you would know that the order is correct. If you want to get really fancy even a Topo Sort would work. Since the hierarchy is defined by the OpenApi Spec (which elements are allowed in which parents) you would know that all nodes are analyzed in the correct order (top to bottom). Not sure if it's worth it 🤷 Probably not as I image you don't have infinite time to spend on this 😆 |
Version and logger have been late additions to the context. It's a bit abuse at the context is supposed to be more like metadata - file/line details, etc. and also to what PHP construct the annotation is related. I think the issue you had is a regression, the PR re-instantiated the previous behviour. I suspect some downstream code might need to switch to using Not sure about the sorting, but I definitly do only have finite time :) |
Hey There,
I found a possible bug (possible because maybe that's intentional? I hope not 😆 ):
Currently all our Docs are generated with OpenAPI 3.0.0 even though some of them should have 3.1.0
I know this has worked in the past so I did some digging:
I have a command that wraps the Generator and basically calls Generator::scan() with different source directories so I can easily create multiple API Docs.
Each of the APIs has a API Class with an OpenApi Annotation including the Version for the API:
Now, when the Generator::generate() Method is called it creates a root context:
swagger-php/src/Generator.php
Lines 496 to 499 in 5ba05b8
The version in the Generator is empty as I want it to use the Version from the Property later on.
The Context defaults back to the Default Version in the constructor, so there is ALWAYS a version set:
swagger-php/src/Context.php
Lines 72 to 75 in 5ba05b8
The ALWAYS part becomes relevant when the Property is later analyzed: There's an if for the OpenApi instance that checks if the version in the root context is set:
swagger-php/src/Annotations/AbstractAnnotation.php
Lines 144 to 151 in 5ba05b8
Now since the constructor defaults back to default version the if can never be false (unless I missed something) so it always takes precedence over the version from the Property (the else branch).
Shouldn't it be the other way around? So, the more specific value in the property is used if set and the default from root only if it doesn't have one?
I assume this changed with b46a36d and is at least somewhat intentional but probably an unintended side effect?
I will probably fix it on my end by trying to find the Api class, get the property and pass the version as config to to generate() but it feels like a workaround.
Let me know what you think.
The text was updated successfully, but these errors were encountered: