[BUG][KOTLIN][RESTCLIENT] Multiple consumes media types overwrite Content-Type header, last one always wins

[bugs84]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• Suggested fix included below

Description

For an operation whose consumes list has more than one media type (e.g.
application/json and multipart/form-data) but that has no formData
parameters — i.e. it uses a plain body parameter and multipart is only listed
because the same endpoint also accepts a file upload variant — the
kotlin generator with library=jvm-spring-restclient emits one
localVariableHeaders["Content-Type"] = "..." assignment per declared consumes
entry, all writing to the same map key. The last entry in consumes always
wins at runtime, regardless of which content type actually matches the body being
sent.

This means every call to the generated method sends the same Content-Type
(whichever media type happens to be listed last in the spec) even when the caller
supplies a JSON body object, not a multipart form. Against a real server this causes
the server to attempt to parse a JSON payload as multipart form data and fail (in our
case, against Alfresco Content Services, it throws a ClassCastException trying to
cast the JSON-deserialized body to a Map).

We hit this generating a client for Alfresco's public
POST /nodes/{nodeId}/children operation
(https://github.com/Alfresco/rest-api-explorer), which legitimately declares:

consumes:
- "application/json"
- "multipart/form-data"

because the endpoint supports both a JSON body and a multipart file-upload body,
but the generated client only ever builds the JSON-body call in our usage — yet
the header is force-set to multipart/form-data.

openapi-generator version

Confirmed present in 7.24.0 (latest stable release) and 7.21.0
(byte-for-byte identical generated output between the two). Also independently
rebuilt and tested against the latest master, commit
c3cde9bd5469e47ed58500b6235e54cc368ce432 / version 7.25.0-SNAPSHOT — again
byte-for-byte identical; the bug is still present.

OpenAPI declaration file content or url

Minimal Swagger 2.0 spec that reproduces the issue (mirrors the real Alfresco
operation shape — body param, multiple consumes, no formData params):

swagger: "2.0"
info:
  title: "Multi-consumes Content-Type bug repro"
  version: "1.0"
basePath: "/api"
paths:
  /nodes/{nodeId}/children:
    post:
      tags:
      - "nodes"
      summary: "Create a node"
      operationId: "createNode"
      parameters:
      - name: "nodeId"
        in: "path"
        required: true
        type: "string"
      - in: "body"
        name: "nodeBodyCreate"
        description: "The node information to create."
        required: true
        schema:
          $ref: "#/definitions/NodeBodyCreate"
      consumes:
      - "application/json"
      - "multipart/form-data"
      produces:
      - "application/json"
      responses:
        "201":
          description: "Successful response"
          schema:
            $ref: "#/definitions/NodeEntry"
definitions:
  NodeBodyCreate:
    type: "object"
    properties:
      name:
        type: "string"
      nodeType:
        type: "string"
  NodeEntry:
    type: "object"
    properties:
      id:
        type: "string"

Generation Details

Gradle plugin invocation (equivalent CLI: generate -g kotlin --library jvm-spring-restclient -i openapi.yaml -o out --additional-properties serializationLibrary=jackson,enumPropertyNaming=UPPERCASE,useSpringBoot3=true):

plugins {
    id("org.openapi.generator") version "7.21.0"
}

openApiGenerate {
    generatorName = "kotlin"
    library = "jvm-spring-restclient"
    inputSpec.set("$projectDir/openapi.yaml")
    outputDir.set("$projectDir/out")
    apiPackage = "repro.api"
    modelPackage = "repro.model"
    packageName = "repro"
    configOptions = mapOf(
        "serializationLibrary" to "jackson",
        "enumPropertyNaming" to "UPPERCASE",
        "useSpringBoot3" to "true",
    )
}

Steps to reproduce

1. Save the spec above as openapi.yaml.
2. Generate with generatorName=kotlin, library=jvm-spring-restclient (config as
   above).
3. Open the generated NodesApi.kt and inspect createNodeRequestConfig().

Actual output

fun createNodeRequestConfig(nodeId: kotlin.String, nodeBodyCreate: NodeBodyCreate) : RequestConfig<NodeBodyCreate> {
    val localVariableBody = nodeBodyCreate
    val localVariableQuery = mutableMapOf<kotlin.String, kotlin.collections.List<kotlin.String>>()
    val localVariableHeaders: MutableMap<String, String> = mutableMapOf()
    localVariableHeaders["Content-Type"] = "application/json"
    localVariableHeaders["Content-Type"] = "multipart/form-data"
    localVariableHeaders["Accept"] = "application/json"
    ...

Content-Type is unconditionally sent as multipart/form-data, even though the
method takes a single JSON-serializable NodeBodyCreate body and no form/multipart
parameters exist at all.

Expected output

Since the operation has no formData parameters, only one Content-Type should be
emitted — the one that actually matches the body being constructed, e.g.:

localVariableHeaders["Content-Type"] = "application/json"

(the first non-multipart entry in consumes, or otherwise a single, well-defined
choice — see "Suggest a fix" below for options).

Related issues/PRs

Searched open and closed issues; the closest related reports are about different
generators/symptoms and are not duplicates of this one:

• [BUG] [kotlin-spring] Multipart with JSON array broken #21306 [BUG][kotlin-spring] Multipart with JSON array broken
• [BUG][Kotlin-Spring] Wrong parameter type for multipart-form-data file upload when using kotlin-spring with reactive #21548 [BUG][Kotlin-Spring] Wrong parameter type for multipart-form-data file upload when using kotlin-spring with reactive
• [BUG] [kotlin-spring] wrong field name and type for multipart #15251 [BUG][kotlin-spring] wrong field name and type for multipart
• [BUG] [JAVA] [RESTCLIENT] [MAVEN] Maven plugin 7.22.0 produces invalid client code to get application/octet-stream #23885 [JAVA][RESTCLIENT] ... Maven plugin 7.22.0 produces invalid client code to get application/octet-stream (response Accept side, java generator)
• [BUG][JAVA][webclient] UnsupportedMediaTypeException if multiple consumes media type and unknown type in first position  #9258 [BUG][JAVA][webclient] UnsupportedMediaTypeException if multiple consumes media type and unknown type in first position (java/webclient library, different template)

None address the kotlin/jvm-spring-restclient request-side Content-Type
overwrite for multi-consumes operations without form params.

Suggest a fix

Root cause is in
modules/openapi-generator/src/main/resources/kotlin-client/libraries/jvm-spring-restclient/api.mustache,
around:

{{^hasFormParams}}{{#hasConsumes}}{{#consumes}}localVariableHeaders["Content-Type"] = "{{{mediaType}}}"
{{/consumes}}{{/hasConsumes}}{{/hasFormParams}}

This iterates over all consumes entries and assigns Content-Type
unconditionally for each, so the last one always wins. Two possible fixes:

1. Minimal/safe: only emit the assignment for the first consumes entry
   ({{#consumes.0}}...{{/consumes.0}} instead of {{#consumes}}...{{/consumes}}),
   matching the existing hasFormParams branch just above it which already uses
   {{#consumes.0}}.
2. More correct: skip media types that don't match the body actually being
   serialized (e.g. skip multipart/form-data/application/x-www-form-urlencoded
   in this branch, since this branch by definition runs only when
   hasFormParams is false and thus no multipart/form body is being built).

Happy to open a PR with option 1 (smallest change, consistent with the sibling
hasFormParams branch's existing use of consumes.0) if maintainers confirm the
preferred approach.

[bugs84]

There is PR:
#24502

For context on the fix approach: I compared how the Java client generator
handles the same "multiple consumes media types" situation, and it turns out
Kotlin's jvm-spring-restclient is an outlier in how it resolves this, not
just in having a bug.

Java (restclient, resttemplate, webclient libraries) — the generated
method builds an array of all declared consumes media types and calls a
runtime helper, apiClient.selectHeaderContentType(contentTypes)
(see Java/libraries/restclient/ApiClient.mustache):

/**
 * Select the Content-Type header's value from the given array:
 *     if JSON exists in the given array, use it;
 *     otherwise use the first non-wildcard one of the array.
 */
public MediaType selectHeaderContentType(String[] contentTypes) {
    ...
    for (String contentType : contentTypes) {
        MediaType mediaType = MediaType.parseMediaType(contentType);
        if (isJsonMime(mediaType)) {
            return mediaType.isWildcardType() || mediaType.isWildcardSubtype()
                ? MediaType.APPLICATION_JSON : mediaType;
        }
    }
    for (String contentType : contentTypes) {
        MediaType mediaType = MediaType.parseMediaType(contentType);
        if (!mediaType.isWildcardType() && !mediaType.isWildcardSubtype()) {
            return mediaType;
        }
    }
    return MediaType.APPLICATION_JSON;
}

This is order-independent and content-aware: consumes: [application/xml, application/json] still correctly resolves to JSON, because it explicitly
prefers JSON over other concrete types rather than just picking positionally.

Java native library uses a Mustache-level {{#-first}} guard — same
"pick one, deterministically" idea as this PR's fix, just already applied
correctly.

Kotlin jvm-spring-restclient has neither mechanism: no
selectHeaderContentType-equivalent exists in its
infrastructure/ApiClient.kt.mustache, and (pre-fix) the template's mustache
loop just unconditionally overwrote a single map key per consumes entry.

What this PR's fix does — and doesn't — solve

The fix in this PR (consumes → consumes.0) makes the Kotlin template match
the simpler native-style convention: always use whichever media type is
listed first in the spec. That's sufficient to fix the reported bug (the
multipart/form-data entry silently and unconditionally winning over
application/json), and is consistent with the sibling hasFormParams branch
in the same template that already does this.

However, unlike Java's selectHeaderContentType, this fix is still
order-dependent: a spec that happens to declare
consumes: [application/xml, application/json] for a plain body-param
operation (no separate multipart variant) would now be locked to XML instead
of JSON, since there's still no runtime logic to prefer JSON regardless of
position.

Suggestion for a follow-up (separate) improvement: port the
selectHeaderContentType pattern into
kotlin-client/libraries/jvm-spring-restclient/infrastructure/ApiClient.kt.mustache
and have api.mustache call it the same way the Java libraries do, instead of
hardcoding a single literal Content-Type at generation time. Happy to open a
follow-up issue/PR for that if maintainers think it's worth doing — wanted to
flag the comparison here first since it's directly relevant to reviewing this
fix's scope and limitations.