fix: apply integer type fitting for Rust params

[holdeg]

We already have logic in postProcessModelProperty to fit integer parameters into the correct Rust primitives. However, this doesn't apply to other kinds of parameters so integer-typed parameters which end up in function calls for Api traits in lib.rs are always i32, even when this is improper.

This commit refactors integer type fitting so that we can run it on both processParam and model post-processing.

Testing

I've included a new RustServerCodegenTest file and an integer-params.yaml test case to cover the new function (and also checked this locally against the API definition which prompted me to contribute this).

PR checklist

• Read the contribution guidelines.
• 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.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  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 ./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.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

---

Summary by cubic

Fixes integer parameter types in the Rust server generator so API trait, client, and server signatures use the correct Rust integer size and signedness instead of defaulting to i32. Applies integer fitting based on format and min/max to both parameters and model properties, and updates samples.

• Bug Fixes

  • Apply integer type fitting to CodegenParameter so generated lib.rs, client, and server use the right Rust integer (including unsigned) rather than i32.
  • Update petstore samples (e.g., integer/int32 -> u32, order_id -> u64).

• Refactors

  • Extract applyIntegerTypeFitting and reuse for parameters and properties; supports int32/int64/uint32/uint64 and min/max constraints.
  • Add a focused test and spec to assert fitted types in lib.rs.

^{Written for commit a8fe886. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 9 files

[wing328]

https://github.com/OpenAPITools/openapi-generator/actions/runs/21522482250/job/62087333292?pr=22853

thanks for the PR

please review the build failure when you've time

[wing328]

cc @frol (2017/07) @farcaller (2017/08) @richardwhiuk (2019/07) @paladinzh (2020/05) @jacob-pro (2022/10) @dsteeley (2025/07)

[dsteeley]

Code changes LGTM. Tests need resolving.
Were all of the samples updated following the code change?

[holdeg]

Thanks both - I did update the samples, so turns out the bug was functional rather than in the tests; we don't apply processing on pathParams in RustServerCodegen.java today, but should (like we do for allParams, headerParams, bodyParams, formParams).

Applying parameter processing there and updating the samples again should fix the issue, although now it looks like my CI is failing on circleCI but I don't really understand what the problem is; looks like a setup failure, are the tests flaky at all?

[wing328]

circleci failure not related to this change