[BUG] [RUST] Empty field structs generated when name conflict between path parameter and response object field of same name using anyOf

[dctaf]

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?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

An anyOf field in a response body named the same as a request parameter causes the Rust generator to generate an empty struct.

This occurs whether anyOf has one variant or two -- the repro below is identical for these two inputs:

  "anyOf": [
    {
      "type": "string"
    },
    {
      "type": "null"
    }
  ]

and

  "anyOf": [
    {
      "type": "string"
    }
  ]

openapi-generator version

v7.16.0

OpenAPI declaration file content or url

{
  "openapi": "3.1.0",
  "info": {
    "version": "0.1",
    "title": "test case"
  },
  "paths": {
    "/api/get/{field_name}": {
      "get": {
        "parameters": [
          {
            "name": "field_name",
            "in": "path",
            "required": true,
            "schema": {
              "type": "string"
            }
          }
        ],
        "operationId": "getter",
        "responses": {
          "200": {
            "description": "description",
            "content": {
              "application/json": {
                "schema": {
                  "properties": {
                    "field_name": {
                      "anyOf": [
                        {
                          "type": "string"
                        }
                      ]
                    }
                  },
                  "additionalProperties": false,
                  "type": "object"
                }
              }
            }
          }
        }
      }
    }
  }
}

Generation Details

$ docker run --rm -v "${PWD}:/local" openapitools/openapi-generator-cli:v7.16.0 generate \
      -i /local/minimal.json \
      -g rust \
      -o /local/openapi-minimal \
      --global-property debugModels,debugOpenAPI

Actual Output

Produces an empty struct for the field:

// getter_200_response.rs
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Getter200Response {
    #[serde(rename = "field_name", skip_serializing_if = "Option::is_none")]
    pub field_name: Option<Box<models::Getter200ResponseFieldName>>,
}

impl Getter200Response {
    pub fn new() -> Getter200Response {
        Getter200Response {
            field_name: None,
        }
    }
}


// getter_200_response_field_name.rs
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Getter200ResponseFieldName {
}

impl Getter200ResponseFieldName {
    pub fn new() -> Getter200ResponseFieldName {
        Getter200ResponseFieldName {
        }
    }
}

Expected Output

1. For this input, I would expect the same as if the "anyOf" was simplified to a simple type: string output:

// getter_200_response.rs
#[derive(Clone, Default, Debug, PartialEq, Serialize, Deserialize)]
pub struct Getter200Response {
    #[serde(rename = "field_name", skip_serializing_if = "Option::is_none")]
    pub field_name: Option<String>,
}

impl Getter200Response {
    pub fn new() -> Getter200Response {
        Getter200Response {
            field_name: None,
        }
    }
}

2. For the anyOf with two variants, I would expect the standard Rust enum variant behavior.

Related issues/PRs

#21896

[awwyushh]

I’ve created a PR that fixes the issue with the Rust generator producing empty structs for anyOf fields named the same as request parameters. The fix simplifies single-variant anyOf to primitive types correctly and handles multi-variant anyOf as expected.

You can verify the fix by running the generator on the provided spec and checking the output structs.

Please let me know if additional tests or changes are needed.
Thanks!

[Mattias-Sehlstedt]

Hi @awwyushh, thanks for implementing a fix.

I would suggested to either adjust an existing rust sample or introduce a new one, where the new behavior is illustrated. This would both help in easily illustrating that the fix is correct, but it would also prevent regression issue for it going forward.

I believe it might be one of these samples that might be of interest.

[julienvincent]

I have the same issue and can confirm the attached PR fixes the problem for me.

[dctaf]

#22056 also fixes related problems (thanks @wing328).