OpenAPITools / OpenAPITools/openapi-generator

[BUG][JAVA] Generator doesn't differentiate between query parameters of the same name in different files

Open
#17,286 1 comment 1 reaction 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
  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator (example)?
  • 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

I'm using multiple files to "group" components.schemas and components.parameters by context. A root file contains all paths which reference the supporting files using the respective file's relative path (ie $ref: './context1.yaml#components/schemas/AModel'). The issue arises when more than one context file defines a parameter using a common name (ie order_by) but with different values and default value defined. In this situation it appears that the generator does not create a unique parameter for each file. Instead, all $refs that have the same terminating name (regardless of path) end up referencing the same parameter (they have the same default value).

openapi-generator version

7.1.0

Spring Server generator

OpenAPI declaration file content or url

File business.yaml:

openapi: 3.1.0
info:
  title: subset1
  version: '1.0'
components:
  parameters:
    order_by:
      name: order_by
      in: query
      required: false
      schema:
        type: string
        enum:
          - name
          - date
          - owner
        default: name
      description: Fields to order the results by

File person.yaml

openapi: 3.1.0
info:
  title: subset1
  version: '1.0'
components:
  parameters:
    order_by:
      name: order_by
      in: query
      required: false
      schema:
        type: string
        enum:
          - age
          - gender
        default: age
      description: Fields to order the results by

File main.yaml

openapi: 3.1.0
info:
  title: subset1
  version: '1.0'
paths:
  /businesses:
    get:
      responses:
        '202':
          description: NO CONTENT
      parameters:
        - $ref: './business.yaml#/components/parameters/order_by'
  /people:
    get:
      responses:
        '202':
          description: NO CONTENT
      parameters:
        - $ref: './person.yaml#/components/parameters/order_by'
Generation Details

Generator configuration (openapi-config.json):

{
  "apiPackage": "com.company.name.api",
  "basePackage": "com.company.name",
  "bigDecimalAsString": true,
  "configPackage": "com.company.name.config",
  "containerDefaultToNull": false,
  "delegatePattern": false,
  "documentationProvider": "source",
  "generatedConstructorWithRequiredArgs": false,
  "interfaceOnly": true,
  "modelPackage": "com.company.name.api.models",
  "openApiNullable": true,
  "reactive": false,
  "useBeanValidation": true,
  "useJakartaEe": true,
  "useResponseEntity": false,
  "useSpringBoot3": true,
  "useTags": true
}

Gradle build configuration:

swaggerSources {
    create("server") {
        setInputFile(file("$rootDir/reference/openapi/base.yaml"))
        code.apply {
            language = "spring"
            configFile = file("openapi-config.json")
            jvmArgs = listOf("--add-opens=java.base/java.util=ALL-UNNAMED")
            dependsOn("validateSwaggerServer")
        }
    }
}
Steps to reproduce
  1. Create a specification file with two unique routes
  2. Define two parameters in separate files with each parameter having a different default value
  3. Pair the routes and parameters using $ref
  4. Generate the server code and examine the default annotation for each parameter. Both will have the same default.
Related issues/PRs

None found

Suggest a fix

I looked at the spring generator but didn't see anything obvious. I suspect this may be an issue with the actual specification file parser.

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

Reproduce the case with main.yaml referencing the two component parameter definitions in business.yaml and person.yaml, then trace the Spring generator and specification parser handling of those $ref values. Done means the generated server code preserves each file's distinct default annotation for the order_by parameter.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, spring
Domain
api, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.