-
-
Notifications
You must be signed in to change notification settings - Fork 134
Something funky is happening with paths after upgrade from 0.13.1 to 0.13.3 #220
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
Comments
I don't think these two are the same. |
Hi @zupo |
Can confirm, having the same issue... |
Prepared test #221 for the use case. Looks like this issue exists in combination with pyramid integration. |
Hmm, OK. Let me take another look at it. |
@svdgraaf: are you using |
I'm generating my own openapi config from AWS ApiGateway, and the order of methods is "random", this works fine on 0.13.1, but on 0.13.3 it started matching the wrong endpoints, eg: I downgraded to 0.13.1 again, and now it works. So something broke in between, haven't looked further yet. |
Now I see the problem. Prepared test with potential fix for the case. |
@p1c2u when you will make new release? |
I maintain an example Pyramid app that uses openapi-core under the hood. When upgrading the library from 0.13.1 to 0.13.3 I've encountered a strange bug: responses fail because they don't match schemas of other endpoints. Weird, right? Read on.
In the PR linked above, you can see that I had to move the endpoint definition for
/articles/{slug}/
to a position after endpoint definitions of more specific endpoints, such as/articles/{slug}/comments
,/articles/{slug}/comments/{id}
and/articles/{slug}/favorite
. Otherwise, a valid request to/articles/{slug}/comments
would fail during response validation withValidationError:'article' is a required property
.It seems that something changed in how paths are registered and this change now requires that more specific subpaths are now defined before less specific paths. I.e.
/item/{id}
needs to be defined below/item/{id}/foo
inopenapi.yaml
file.I haven't yet managed to isolate this bug further. @p1c2u do you have any ideas off the top of your head what could cause this?
The text was updated successfully, but these errors were encountered: