-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
Ambiguous paths that should not be 0.10.0 #504
Comments
hmmm... I see this also, will investigate, I don't think this rule changed at all. |
The code has not changed at all in this area to suddenly start changing the behavior of this rule. Looking at the logic and looking at your spec.. it's behaving correctly.
Are actually ambiguous. /a/ <-- matches
These two paths can both be
|
But this should be allowed in the openapi specification as far as I can read. Id2 is required to be an integer and c is not one. Why would this then still be ambiguous? I see the point if Id2 could be anything but it can't. And the behavior changed this I know. Though i don't know why if there has been no change to it. And why then does the first two work and not the next two, should it not be the same case for those?
npm i -g @quobix/[email protected] It does not give any errors for this one. npm i -g @quobix/[email protected] This version gives the errors. |
The rule is not checking the types of the parameters, it is just looking at the paths themselves and the parameter positions on the path. So the logic is accurate - what is missing is a parameter type check also. That would be an upgrade. I will recompile 0.9.16 from source and re-run this test. Because I am confused as to how the version change altered behavior, this code has not been touched (the logic in the rule anyway). |
OK the reason why In this case Because the built in rule was calling the wrong thing. ( There were a few of these issues that were cleared up in |
This logic was also lifted from the spectral rule of the same name. It's the same logic, just implemented in a different language. |
So untill the rule is updated with support for types I assume the only thing we can do is to disable the rule? Or is there some other thing I can do? |
Yes, it's due for an upgrade soon anyway - but there is no timeline available. The only option is to disable the rule. |
@Ryefalk , @daveshanley notice that there are long running ticket on path templating model in OAS , so it s no 100 % clear (at least to me) if those path should be considered as ambigous or not |
When running vacuum 0.10.0 Two paths that should not be ambiguous are flagged as such. But the simpler example it can manage. This problem did not exist in the previous version we used 0.9.10 so somewhere between these two versions this problem appeared.
This is a minimal working example of the issue.
The text was updated successfully, but these errors were encountered: