-
Notifications
You must be signed in to change notification settings - Fork 197
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
Rocket: Incorrectly derived query parameters defined as <foo..>
#1070
Comments
Right, I suppose this is with the latest beta since there is at least the openapi 3.1 going on. Those |
Ah yes, I forgot to mention that I am using 5.0.0-beta.0. If you give me a couple code pointers, I'd be happy to send a PR. |
Okay, sure. First you should run the code with {
"cargo": {
"buildScripts": {
"rebuildOnSave": false
},
"noDefaultFeatures": true,
"features": [
"debug",
"chrono",
"time",
"rocket_extras",
"uuid",
"decimal",
"smallvec",
"macros",
"repr",
"config"
]
}
} Then the code for this lives in Line 1702 in 8d5149f
The interesting part should be in here, what happens here: Lines 1757 to 1770 in 8d5149f
|
Thanks! I'll take a look tomorrow. |
I don't think this is as trivial to fix as I thought. The parameter resolution just takes into account the function arguments. There's no way to get the contents of |
Right, if it gets to that, then for sure that is not really possible in any realistic terms. And yes because from code like below, there is no way to distinct the
|
This commit fixes the trailing query parameters wrapped in `Option<T>`. Option wrapped query parameters were mistaken to value parameters and treated incorrectly. Fixes #1070
There was actually bug in resolving trailing query parameters. If the #[get("/list?<page..>")]
async fn list_items(
page: PageParams,
) {} |
This commit fixes the trailing query parameters wrapped in `Option<T>`. Option wrapped query parameters were mistaken to value parameters and treated incorrectly. Fixes #1070
I'm trying to add pagination query parameters to some endpoints in my Rocket 0.5 project.
I originally defined my endpoint like this:
This cased the following to be emitted in the
parameters
field in the spec:To attempt to work around it, I figured out how I'm actually supposed to use
IntoParams
.I originally defined my endpoint like this:
This emits the parameters correctly, but it still emits the incorrect, auto derived
page
parameter too.The text was updated successfully, but these errors were encountered: