2.7.54 OpenAPI export breaking Orval compatibility

Get Support
1

Updating to version >2.7.53 breaks compatibility with Orval.

:beers: orval v7.17.0 - A swagger client generator for typescript
apiClient: Cleaning output folder
:octagonal_sign: apiClient - Error: Duplicate schema names detected:
  9x Response
    at writeSchemas (/app/node_modules/@orval/core/dist/index.js:3245:41)
    at async Promise.all (index 0)
    .....

Probable Issue:
When exporting OpenAPI specs, response components now use $ref to reference components/responses, but the schemas inside these responses are inline and unnamed:

v2.7.53
:zap:[Optimization] OpenAPI/Swagger specs import and export now support response components.

// before (working with Orval)
        '500':
          description: ''
          content:
            application/json:
              schema:
                title: ''
                type: object
                properties:
                  message:
                    type: string
                required:
                  - message
          headers: {}

// after (not working with Orval)
        '500':
          $ref: '#/components/responses/サーバーエラー'
          description: ''
--------------------------------------
    サーバーエラー:
      description: ''
      content:
        application/json:
          schema:
            title: InternalServerErrorResponse
            type: object
            properties:
              message:
                type: string
            required:
              - message

Environment:

  • Apidog Version: 2.7.54
  • Tool affected: Orval v7.17.0
  • Export format: OpenAPI 3.0 YAML
  • OS: macOS

Possible Fixes:
Please add an export setting to control response component behavior, or automatically generate named schemas when using response components.

Also, would it be possible to download an earlier version (2.7.51) so I can continue working while this is fixed?

Thank you for your support.

P.S. should I have posted this in bug-report?

2

I couldn’t reproduce this issue. Could you please provide a minimal OpenAPI JSON file that demonstrates the problem?

3

Thank you for the quick response!

I uploaded three files, orval config + apidog yaml file for minimal reproduction, and the script I am currently using to roll back the yaml file.

Please let me know if there is anything else I can share.
Also, is it possible to download older versions of apiDog?
orval.config.ts|nullxnull
api-spec-latest.yaml|nullxnull
fix-api-spec.js|nullxnull

4

Thank you for the detailed information. After investigating, I found that Orval removes all non-ASCII characters when converting OpenAPI components. Your response components contain two Japanese names, which become identical after conversion, causing the error.

Since using non-ASCII characters in response names can cause compatibility issues with OpenAPI tools, we recommend using ASCII characters for response names.

You can download the previous version (2.7.53) here:
Windows: https://file-assets.apidog.com/download/2.7.53/Apidog-2.7.53.exe
macOS: https://file-assets.apidog.com/download/2.7.53/Apidog-2.7.53.dmg
macOS Arm64: https://file-assets.apidog.com/download/2.7.53/Apidog-macOS-arm64-2.7.53.dmg

5

We recommend changing your response component names to English to avoid this compatibility issue with Orval. We’ll consider adding an “alias” feature for response components in the future, which would allow you to use Japanese names in aliases while keeping the main identifiers ASCII-compatible. This should help prevent similar issues.

6

Thank you for the investigation!
I will try changing all the components names to ASCII characters, the option of having an ASCII only name with non-ASCII alias would indeed be a nice addition.