OpenAPITools
[Rust-Axum] Fix uuid in header params causing compilation errors
Routes with header parameters with a format of uuid in the openAPI specification used to cause a compilation error in the resulting Rust Axum code.
This commit fixes the issue by including the correct conversion trait implementation on the condition that at least one header parameter of format uuid is included in the specification.
Problem details: #18554
How to validate:
The faulty behavior can be reproduced like this:
On the current master branch generate a Rust axum library with the specification described in #18554 .
Then (when you have installed rustc and cargo, run cargo check in the rust workspace containing the generated library. You will get compile errors in the places where the uuid is extracted from the request headers.
To verify the fix do the same with the code changes contained in this pull request.
Now cargo check will not report any compilation errors. Note the change in the src/header.rs file. A few lines have been added to it.
PR checklist
- [x] Read the contribution guidelines.
- [x] Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
- [x] Run the following to build the project and update samples:
(For Windows users, please run the script in Git BASH) Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example./mvnw clean package ./bin/generate-samples.sh ./bin/configs/*.yaml ./bin/utils/export_docs_generators.sh./bin/generate-samples.sh bin/configs/java*. IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed. - [x] File the PR against the correct branch:
master(upcoming 7.1.0 minor release - breaking changes with fallbacks),8.0.x(breaking changes without fallbacks) - [x] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. @frol @farcaller @richardwhiuk @paladinzh @jacob-pro
Thank you very much for having reviewed the PR so far. I have made the changes you described and hope to not have made any mistakes.
Thanks for the PR but your commit (as shown in the Commits tab) is not linked to your Github account, which means this PR won't count as your contribution in https://github.com/OpenAPITools/openapi-generator/graphs/contributors.
Let me know if you need help fixing it.
Ref: https://github.com/OpenAPITools/openapi-generator/wiki/FAQ#how-can-i-update-commits-that-are-not-linked-to-my-github-account
Sorry for causing so much work with this PR. Now I have rebased the history so that the e-mail aligns with my GitHub account.
I will change the integration test for this change because the same bug I have fixed for the rust-axum generator exists for the rust-server generator also. So I will create a new test that is only run during the integration test of the rust-axum generator. Then in an another PR, if I have the time, I will fix the same bug in the rust-server generator.
I found time to add a clean integration test for the changes to the rust-axum generator. The relevant samples are updated and the relevant integration test passes. Please inform me if there is anything I can/should do differently.
https://github.com/OpenAPITools/openapi-generator/actions/runs/8958257509/job/24603984954?pr=18563
the build failure doesn't seem to be related to this PR, right?
Yes this is an unrelated error. I can try to tackle this together with #18572
https://github.com/OpenAPITools/openapi-generator/actions/runs/8958257509/job/24603984954?pr=18563
the build failure doesn't seem to be related to this PR, right?
I created a PR that should resolve the problem of the failing test. I could not reproduce a failing build on my local system I do not know why, but I adjusted the code so that the problem you cited should be solved.
merged https://github.com/OpenAPITools/openapi-generator/pull/18575
@linxGnu when you've time, can you please review this PR? Thank you.
@myz-dev both of your PR, please ensure that you pass Integration Test. It's critical to verify.
LGTM. Please also trying to use latest uuid crate.
Hi. The template includes (in Cargo.mustache):
uuid = { version = "1", features = ["serde"] }
This means the newest 1.x version of uuid is going to be pulled for the build.
If I look into samples/server/petstore/rust-axum/Cargo.lock I see this:
[[package]]
name = "uuid"
version = "1.8.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "a183cf7feeba97b4dd1c0d46788634f6221d87fa961b305bed08c851829efcc0"
dependencies = [
"serde",
]
With 1.8.0 being the latest release: https://crates.io/crates/uuid
If I did not misunderstand your comment, the latest version of uuid is already used.
@myz-dev both of your PR, please ensure that you pass Integration Test. It's critical to verify.
Sorry can you please explain what test does not pass? When I run
mvn integration-test -f samples/server/petstore/rust-axum/pom.xml I get a passing test:
...
[INFO] --- exec:1.2.1:exec (clippy) @ RustServerTests ---
Checking rust-axum-header-uui v0.1.9 (/home/myz/Workspace/Varta/openapi-generator/samples/server/petstore/rust-axum/output/rust-axum-header-uuid)
Finished dev [unoptimized + debuginfo] target(s) in 0.80s
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 35.042 s
[INFO] Finished at: 2024-05-07T11:41:50+02:00
@myz-dev
- uuid already latest -> nice, thank you for double checking
- It looks good when tests
mvn integration-test -f samples/server/petstore/rust-axum/pom.xmlare passed
Then LGTM