OpenAPITools / OpenAPITools/openapi-generator

[BUG][SCALA] Cannot Output Multiple Response Types

Open
#6,318 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Issue: Bug
Dominant language
Java
Stars
26.8k
Forks
7.7k
PR merge metrics
PR metrics pending

Description

Bug Report Checklist
  • [Y] Have you provided a full/minimal spec to reproduce the issue?
  • [N] Have you validated the input using an OpenAPI validator (example)?
  • [Y] What's the version of OpenAPI Generator used?
  • [Y] Have you search for related issues/PRs?
  • [Y] What's the actual output vs expected output?
  • [Optional] Bounty to sponsor the fix (example)
Description

We have an endpoint (see yaml below) which has a body defined for a success, but a different body defined for an error response.
However, ApiInvoker expects a Manifest typed on the success response for all cases. The if statement on this case https://github.com/OpenAPITools/openapi-generator/blob/26830bf3bcfa02a79bfda49a2e695391f9189c3d/modules/openapi-generator/src/main/resources/scala-akka-client/apiInvoker.mustache#L251 checks for this. If it doesn't match (as in our error case) it then ends up in this case (https://github.com/OpenAPITools/openapi-generator/blob/26830bf3bcfa02a79bfda49a2e695391f9189c3d/modules/openapi-generator/src/main/resources/scala-akka-client/apiInvoker.mustache#L260) and you get the ConfigServiceError as a string (which isn't what you need).
A workaround is to use asInstanceOf to change the ApiRequest to be typed on the error type, but that isn't practical outside of testing.

openapi-generator version

4.3.0

OpenAPI declaration file content or url
openapi: '3.0.0'
paths:
  /api/v1/config/revision:
    post:
      summary: Add a revision
      description: Add a revision of configuration without applying it
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/RevisionRequest'
      responses:
        '201':
          description: Success
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/RevisionResponse'
        '400':
          description: BadRequest
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/ConfigServiceError'
      security:
        - bearerAuth: []
      tags:
        - config
components:
  schemas:
    ConfigServiceError:
      description: A config service error
      type: object
      required:
        - type
      properties:
        type:
          type: string
        errors:
          type: array
          items:
            type: string
          description: The errors
Command line used for generation

Scala, openapi-generator(4.3.0) (but code affected same in master)
sbt clean openapiGenerate

Steps to reproduce

Use an ApiInvoker typed on the success response in an error scenario, and try to unmarshall the error response.

Related issues/PRs

#1096
#316
#3377

Suggest a fix

Have the ApiInvoker and internal map take multiple types? Type the ApiResponse with multiple types (success/failure)? Remove/amend the if from the case statement?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with modules/openapi-generator/src/main/resources/scala-akka-client/apiInvoker.mustache, especially the response handling around lines 251 and 260. Regenerate the Scala client with sbt clean openapiGenerate using the supplied OpenAPI declaration, reproduce the 400 response, and verify that it is unmarshalled as ConfigServiceError while the 201 response remains RevisionResponse.

Written by the indexing model from the issue text.

Assessment

Tech stack
openapi, scala
Domain
api, tooling
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.