[BUG][Java] Nested <OperationId>Request class collides with request body model, breaking existing methods

Abierto
  • ¿Algo no está bien?
#25,646 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java, openapi
Área
backend-api-design, tooling

Línea de trabajo

Read Java/libraries/webclient/single_request_parameter.mustache and inspect the Java WebClient generator tests for useSingleRequestParameter. The issue includes a minimal OpenAPI spec shape, though it has not been run separately; generate a client with that shape and inspect the *Api class. Done means the generated nested request class no longer shadows the body model and positional callers can still pass that model.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Issue: Bug
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?
Description

With useSingleRequestParameter set to true or static, the Java client generates a nested class named <OperationId>Request inside each *Api class. When a request body model has that same name, the nested class shadows the model inside the *Api class:

  • The existing positional method's body parameter now resolves to the nested class, so existing callers that pass the model no longer compile.
  • The nested class's body field is typed as the nested class itself, so there is no way to send the real body.

Enabling the option is expected to be additive (the positional methods are still generated), but in this case it breaks the existing API.

openapi-generator version

Seen with 7.14.0 and 7.27.0 (Gradle plugin). On master, Java/libraries/webclient/single_request_parameter.mustache uses the same <OperationId>Request naming with no collision handling.

OpenAPI declaration file content or url

Minimal spec showing the shape (an operation updateFoo whose request body model is UpdateFooRequest). The behaviour was observed on a larger spec with the same pattern; this reduced version has not been run separately.

openapi: 3.0.3
info: { title: repro, version: "1" }
paths:
  /foo/{id}:
    patch:
      operationId: updateFoo
      parameters:
        - { name: id, in: path, required: true, schema: { type: string } }
      requestBody:
        required: true
        content:
          application/json:
            schema: { $ref: '#/components/schemas/UpdateFooRequest' }
      responses:
        '200': { description: ok }
components:
  schemas:
    UpdateFooRequest:
      type: object
      properties:
        name: { type: string }
Generation Details

generatorName: java, library: webclient, useSingleRequestParameter: static (same result with true).

Steps to reproduce
  1. Generate a Java webclient client from the spec above with useSingleRequestParameter set to static or true.
  2. Look at the generated *Api class.

Actual: a nested public static class UpdateFooRequest containing private UpdateFooRequest updateFooRequest. The positional updateFoo(String id, UpdateFooRequest updateFooRequest) now resolves to the nested class, so code passing the model UpdateFooRequest fails with incompatible types: <model>.UpdateFooRequest cannot be converted to <Api>.UpdateFooRequest.

Expected: no shadowing, for example by giving the request class a non-colliding name (such as UpdateFooRequestParams) or by using fully qualified model names in signatures when a collision exists.

Related issues/PRs

#19827 (adds the option to WebClient), #20679, #24568. I did not find an existing issue for this collision.

Lenguaje dominante
Java
Estrellas
26.9k
Forks
7.8k
Merge medio
2 d 10 h
PR fusionados (30 d)
180

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenAPITools/openapi-generator

Todos los issues de OpenAPITools/openapi-generator

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.