-
-
Notifications
You must be signed in to change notification settings - Fork 4
Wrong format for UUID in open api #53
Hello Tunay, it's me again 😊
It looks like the framework has problems with a UUID in a path. I'm sure it worked at one point.
Simple handler:
/// Get a pin by ID #[rustapi_rs::get("/pins{id}")] #[rustapi_rs::tag("Pins")] #[rustapi_rs::summary("Get Pin")] #[rustapi_rs::description("Read a pin by id.")] async fn read( State(state): State<AppState>, Path(id): Path<Uuid>, ) -> Result<Json<Pin>> { let pin = Pin::default(); Ok(Json(pin)) }
The generated definition in /docs/openapi.json:
"/pins{id}": { "get": { "description": "Read a pin by id.", "parameters": [ { "in": "path", "name": "id", "required": true, "schema": { "format": "int64", "type": "integer" } } ], "responses": { "200": { "content": { "application/json": { "schema": { "$ref": "#/components/schemas/Pin" } } }, "description": "Successful response" }, "400": { "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorSchema" } } }, "description": "Bad Request" }, "500": { "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ErrorSchema" } } }, "description": "Internal Server Error" } }, "summary": "Get Pin", "tags": [ "Pins" ] } },
Here the id is intepreted as integer and not as UUID.
Best regards,
Peter
All reactions
-
👀 1
Good Morning @PeterGumball
I’ve updated to v0.1.195, and it’s now parsing correctly in my local test environment.
just cargo update
If you can share the exact code snippet you tested with, I’d be happy to look into it further and try to come up with an even better solution.
Also, thank you for your valuable thoughts and feedback this kind of motivation really keeps me going, and I’ll continue improving the project.
Replies: 4 comments 6 replies
Thanks for reporting this 🙏
I’ve started investigating the issue with UUID being generated as int64 in the OpenAPI schema.
Once I finish analyzing it, I’ll open a dedicated GitHub Issue and share the link here so we can track progress properly.
Thank you!
Tunay
All reactions
Hi, thanks a lot for the report and for taking the time to write this 🙌
The issue is resolved, and I’m currently double-checking a few related parts as well.
I’ll be pushing the necessary crate updates very soon.
You can follow the progress from here #54 , and feel free to ping me if you notice anything else.
Thanks again!
All reactions
Hi @PeterGumball,
I’ve fixed the issue you reported with the UUID format in the OpenAPI schema. Could you please try again and see if everything works now?
If you still encounter any problems, feel free to ping me again. I’ll be happy to take another look!
Thanks! 🚀
All reactions
Hey Tunay.
I set the version to 1.1.15 and rebuilt everything. Unfortunately, the error is still there.
In addition, I now get the following error with the post handler
/// Create a new pin #[rustapi_rs::post("/pins")] #[rustapi_rs::tag("Pins")] #[rustapi_rs::summary("Create pin")] #[rustapi_rs::description("Creates a new pin.")] async fn create( State(state): State<AppState>, ValidatedJson(payload): ValidatedJson<CreatePin>, ) -> Result<Created<Pin>> { let pin = CreatePin::default(); Ok(Created(pin)) }
error[E0277]: the trait bound `fn(State<AppState>, ValidatedJson<CreatePin>) -> impl Future<Output = Result<Created<Pin>, ApiError>> {create}: Handler<_>` is not satisfied
--> src/features/pins/handler.rs:11:10
|
7 | #[rustapi_rs::post("/pins")]
| ---------------------------- required by a bound introduced by this call
...
11 | async fn create(
| ^^^^^^ the trait `Handler<_>` is not implemented for fn item `fn(State<AppState>, ValidatedJson<CreatePin>) -> impl Future<Output = Result<Created<Pin>, ApiError>> {create}`
|
note: required by a bound in `post_route`
--> /Users/peter/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustapi-core-0.1.15/src/handler.rs:452:8
|
450 | pub fn post_route<H, T>(path: &'static str, handler: H) -> Route
| ---------- required by a bound in this function
451 | where
452 | H: Handler<T>,
| ^^^^^^^^^^ required by this bound in `post_route`
All reactions
-
👀 1
Hi Peter,
Thanks a lot for the feedback! I’ve fixed this issue in v0.1.191. (I've worked a little on versioning, sorry for my amateurism. I'm doing my best.)
Root cause:
rustapi-macros was not properly analyzing the inner type of Path<T>. When it encountered Path<Uuid>, it defaulted to an integer/int64 schema instead of resolving the actual type.
Fix:
I updated the macro logic to analyze function signatures more accurately. It now correctly detects Path<Uuid> and automatically generates the proper OpenAPI schema:
type: string format: uuid
Usage:
No changes are required on your side. Your existing code should now work as expected:
#[rustapi_macros::get("/pins/{id}")] async fn get_pin(Path(id): Path<Uuid>) -> Json<Pin> { ... }
You can upgrade using cargo update.
If you run into any other issues, feel free to ping me. 🚀
Thanks again!
All reactions
Hello Tonay.
Still doesn't seem to work, UUID is still being parsed as integer/In64.
And don't say you're an amateur, you're doing a great job. I wouldn't have the energy to do something like that anymore. I'm already over 50 😊
Keep up the good work.
All reactions
-
👀 1
Good Morning @PeterGumball
I’ve updated to v0.1.195, and it’s now parsing correctly in my local test environment.
just cargo update
If you can share the exact code snippet you tested with, I’d be happy to look into it further and try to come up with an even better solution.
Also, thank you for your valuable thoughts and feedback this kind of motivation really keeps me going, and I’ll continue improving the project.
All reactions
Now it works. Thank you.
My code is hosted at Codeberg as private repository. If you have an account there, or create one, then i can show you my code.
All reactions
-
❤️ 1
I've heard a lot about Codeberg. My username is "Tunti35"
Thanks in advance.
Best regards
All reactions
I've added you as a "reader".
All reactions
-
❤️ 1