In client code generation for typed objects, handling one response model for success and one for errors

Description

(There are similar issues but nothing exactly the same as this I believe? eg #3371 and #4398 - apologies if I missed an open item that this duplicates)

I am generating clients in java and scala from a Swagger JSON object (itself generated from swagger-spray). Pretty much all my endpoints have a single model for 2xx responses, and a single model for 4xx/5xx responses, eg:

        "responses": {
          "202": {
            "description": "The shutdown command was issued successfully, use the \"GET\" command on the /{cluster_id} resource to monitor progress",
            "schema": {
              "$ref": "#/definitions/EmptyResponse"
            }
          },
          "404": {
            "description": "The cluster specified by {cluster_id} cannot be found (code: 'clusters.cluster_not_found')",
            "schema": {
              "$ref": "#/definitions/BasicFailedReply"
            }
          },

when generating a client eg in scala, the endpoint returns Option[Any] (and in java Object instead of Any) pointing to a Map instead of (eg in the above example) EmptyResponse. If I only add a single response class then it correctly assigns the class to the endpoint return value.

So it seems that it treats >1 response class differently (reasonably!) but doesn't take into account that all 4xx/5xx responses are captured as ApiExceptions, so can be ignored as far as the return type of the endpoint is concerned?

Glancing over the code (and in the short term thinking selfishly about how i can quickly generate a better typed client for my own purposes!), could it be as simple as discarding responses associated with errors here?

Swagger-codegen version

v2.2.2

Swagger declaration file content or url

(see JSON fragment above, can gist a standalone JSON file or our entire API if useful)

Command line used for generation

swagger-codegen generate -i api-coverage-tests/src/main/resources/apidocs.json -l scala -o api-coverage-tests/generated --additional-properties modelPropertyNaming=original --api-package org.elastic.cloud.apiclient --model-package org.elastic.cloud.apiclient.model

Steps to reproduce

(can provide a minimal reconstruction later if helpful)

Related issues

• #3371
• #4398

Suggest a Fix

Nothing concrete yet, happy to PR if there is a desirable solution

Start at DefaultCodegen.java around the linked response-handling code, using the JSON responses fragment and the Scala generation command as the reproduction context. Compare the generated Scala and Java return types when 2xx and 4xx/5xx models are both present, then verify that successful responses use EmptyResponse while error responses remain handled as ApiExceptions.