[BUG] [rust-server] Generated client ignores multiple content types in response, fails at runtime when server returns non-first media type #24097

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?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

The rust-server generator does not support responses that declare multiple content types (media types). When an OpenAPI response object specifies more than one content type (e.g. both text/plain and application/json), the generator silently picks only the first one and ignores the rest. The generated client then hard-codes deserialization for that single content type.

This means that if the server responds with a different (but spec-valid) content type, the generated client fails at runtime with a deserialization error rather than handling it gracefully.

Per the OpenAPI 3.0 specification, a response with multiple content types is valid and clients should inspect the Content-Type header to determine how to deserialize the body. The current rust-server generator violates this by assuming a single fixed type.

Example failure scenario: An API declares a 403 Forbidden response with both text/plain (for a plain error string) and application/json (for a structured error object). The server returns text/plain on 403. The generated client attempts to parse the body as JSON, fails with "Response body did not match the schema: expected value at line 1 column 1", and throws an ApiError instead of surfacing the response to application code.

openapi-generator version

he issue exists in the current master branch (7.x series). It is not a regression in the sense that the generator has never supported multiple content types per response — but it is a gap relative to what the OpenAPI specification allows.

OpenAPI declaration file content or url

openapi: 3.0.2
info:
  version: 1.0.0
  title: Example API

paths:
  /resource:
    post:
      operationId: createResource
      responses:
        '201':
          description: Created
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Resource'
        '403':
          description: Forbidden
          content:
            text/plain:
              schema:
                type: string
            application/json:
              schema:
                $ref: '#/components/schemas/Error'

components:
  schemas:
    Resource:
      type: object
      properties:
        id:
          type: string
    Error:
      type: object
      required:
        - message
      properties:
        message:
          type: string

Generation Details

openapi-generator-cli generate \
  -g rust-server \
  --input-spec example.yaml \
  -o output/

No special configuration or additional properties required to reproduce.

Steps to reproduce

1. Create a spec with a response that has multiple content types (as above).
2. Generate with rust-server.
3. Observe that the generated client code for the 403 response only handles one content type.
4. At runtime, if the server returns text/plain (which is valid per the spec), the client fails with:

   ApiError("Response body did not match the schema: expected value at line 1 column 1")
   

Expected behaviour: The generated client should check the Content-Type response header and deserialize accordingly — e.g. using swagger::OneOf2<Error, String> to represent the two possible body types, with a runtime match on the content type

Related issues/PRs

• PR [Core/Rust Server] Support multiple request body/response body types #19411 — [Core/Rust Server] Support multiple request body/response body types by @richardwhiuk (opened 2024-08-21, still open). This PR directly implements the fix for this issue by adding schemaVariants support to DefaultCodegen and the rust-server templates. It adds opt-in support via supportsMultipleRequestTypes / supportsMultipleResponseTypes flags.

• PR [rust-axum] Add support for multiple response types and streaming responses #22095 — [rust-axum] Add support for multiple response types and streaming responses (open). Related but for the rust-axum generator rather than rust-server.

Suggest a fix

PR #19411 already providesa fix but given that was still open I wasn't sure if it was the correct one.

The relevant code path that currently drops extra content types is in ModelUtils.getSchemaFromContent():

// modules/openapi-generator/src/main/java/org/openapitools/codegen/utils/ModelUtils.java
private static Schema getSchemaFromContent(Content content) {
    if (content == null || content.isEmpty()) {
        return null;
    }
    if (content.size() > 1) {
        LOGGER.warn("Multiple schemas found in content, returning only the first one");
    }
    MediaType mediaType = content.values().iterator().next();
    return mediaType.getSchema();
}