[rust] fix: map-typed query parameters do not compile (.to_string() on a HashMap)

[wiebren]

A map-typed query parameter (type: object with typed additionalProperties, generated as HashMap<String, T>) falls through to the scalar path in several template branches, which call .to_string() on it. HashMap has no Display, so the crate does not compile:

error[E0599]: `HashMap<std::string::String, std::string::String>` doesn't implement `std::fmt::Display`
error[E0599]: the method `to_string` exists for reference `&HashMap<std::string::String, i32>`,
              but its trait bounds were not satisfied

branch	reqwest	reqwest-trait
required, non-nullable	.to_string(): broken	.to_string(): broken
required, nullable, non-deepObject	JSON-encoded: ok	.to_string() fallthrough: broken
optional, non-deepObject	JSON-encoded: ok	.to_string() fallthrough: broken
deepObject + explode	handled	handled

Fix

An {{#isMap}} split at each hole serializes the map with serde_json::to_string, as reqwest's optional non-primitive branch already does. No wire change for anything that compiled before: isMap also covers a bare free-form object (serde_json::Value), which moves from .to_string() to serde_json::to_string(..)?, and those produce the same JSON.

Verification

• RustClientCodegenTest#testMapQueryParamsSerializeAsJson runs the fixture through both libraries and fails without the templates.
• cargo build is clean with the fix and fails with E0599 without it.
• Samples: zero diffs.

Known gaps

A required non-nullable style: deepObject map is sent as one JSON parameter. That branch never had deepObject handling (for maps it did not compile before); deepObject serialization is #24899's scope.

Related

Follow-up to #24866.

PR checklist

• Read the contribution guidelines.
• Built the project and updated samples (./bin/generate-samples.sh ./bin/configs/rust-*): zero diffs.
• Technical committee (Rust): @frol @farcaller @richardwhiuk @paladinzh @jacob-pro @dsteeley

---

Summary by cubic

Fixes Rust client codegen for map-typed query parameters, which previously emitted .to_string() on a HashMap (it has no Display/ToString) and failed to compile in reqwest and reqwest-trait. Maps now serialize as a single JSON-encoded query parameter via serde_json::to_string, matching how non-primitive parameters are already handled. No behavior change for parameters that compiled before.

• Adds a test fixture and regression test covering required and optional map query params in both libraries.
• A required non-nullable style: deepObject map still sends as one JSON parameter; deepObject serialization remains out of scope.

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

---

Generated with Claude Code

[cubic-dev-ai]

1 issue found across 4 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="modules/openapi-generator/src/main/resources/rust/reqwest/api.mustache">

<violation number="1" location="modules/openapi-generator/src/main/resources/rust/reqwest/api.mustache:170">
P3: A required, non-nullable map declared with `style: deepObject` falls into this `{{#isMap}}` branch and is serialized as a single JSON-encoded parameter (`labels={...}`) instead of the deep-object `labels[key]=value` form. The template only implements deepObject spreading inside the `{{#isNullable}}` branch, so required non-nullable deep-object maps bypass it. Previously this path emitted `.to_string()` and did not compile, so this is an incomplete fix, not a regression, but the wire format is now silently wrong for that style.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: A required, non-nullable map declared with style: deepObject falls into this {{#isMap}} branch and is serialized as a single JSON-encoded parameter (labels={...}) instead of the deep-object labels[key]=value form. The template only implements deepObject spreading inside the {{#isNullable}} branch, so required non-nullable deep-object maps bypass it. Previously this path emitted .to_string() and did not compile, so this is an incomplete fix, not a regression, but the wire format is now silently wrong for that style.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/main/resources/rust/reqwest/api.mustache, line 170:

<comment>A required, non-nullable map declared with `style: deepObject` falls into this `{{#isMap}}` branch and is serialized as a single JSON-encoded parameter (`labels={...}`) instead of the deep-object `labels[key]=value` form. The template only implements deepObject spreading inside the `{{#isNullable}}` branch, so required non-nullable deep-object maps bypass it. Previously this path emitted `.to_string()` and did not compile, so this is an incomplete fix, not a regression, but the wire format is now silently wrong for that style.</comment>

<file context>
@@ -166,7 +166,12 @@ pub {{#supportAsync}}async {{/supportAsync}}fn {{{operationId}}}(configuration:
     {{^isArray}}
     {{^isNullable}}
+    {{#isMap}}
+    req_builder = req_builder.query(&[("{{{baseName}}}", &serde_json::to_string(&{{{vendorExtensions.x-rust-param-identifier}}})?)]);
+    {{/isMap}}
+    {{^isMap}}
</file context>

[wiebren]

Accurate, and worth separating from this PR's scope. That branch - required, non-nullable - has never had any isDeepObject handling at all: unlike the nullable and optional paths just below it, it goes straight to the scalar form for every type. So a required non-nullable style: deepObject map was not previously exploded either; it did not compile at all, which is what this PR fixes. The json encoding it now produces is the same shape the other libraries' non-primitive parameters use, so nothing regresses - but you are right that it is not the declared style.

The deepObject format work lives in #24899, which routes exploded deepObject maps through parse_deep_object (both the free-form and the typed-map shape). Extending that to the required non-nullable branch is a small addition and I am happy to push it - I would suggest doing it there rather than here, so all deepObject encoding stays in one PR and these two do not both edit the same template lines. Say which you prefer and I will add it.