[BUG] std::option::Option<&str> cannot be formatted with the default formatter

[mickvangelderen]

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 the rust generator to generate a client for our kubernetes API server.

The generated client code fails to compile with:

error[E0277]: `std::option::Option<&str>` doesn't implement `std::fmt::Display`
    --> kubernetes-client/src/apis/core_v1_api.rs:3872:67
     |
3872 |     let local_var_uri_str = format!("{}/api/v1/nodes/{name}/proxy/{path}", local_var_configuration.base_path, name=crate::apis::urlencode(name));
     |                                                                   ^^^^^^ `std::option::Option<&str>` cannot be formatted with the default formatter

The generated code:

/// connect POST requests to proxy of Node
pub async fn connect_core_v1_post_node_proxy_with_path(configuration: &configuration::Configuration, name: &str, path: Option<&str>) -> Result<String, Error<ConnectCoreV1PostNodeProxyWithPathError>> {
    let local_var_configuration = configuration;

    let local_var_client = &local_var_configuration.client;

    let local_var_uri_str = format!("{}/api/v1/nodes/{name}/proxy/{path}", local_var_configuration.base_path, name=crate::apis::urlencode(name));
    let mut local_var_req_builder = local_var_client.request(reqwest::Method::POST, local_var_uri_str.as_str());
   
    // ...
}

openapi-generator version

Happens on:

• 7.10.0
• 7.11.0-SNAPSHOT

OpenAPI declaration file content or url

Can't share but it is a Kubernetes OpenAPI V2 spec.

Generation Details

docker run --rm --network=host -v ${PWD}:/local openapitools/openapi-generator-cli \
    generate \
    -i https://apiserver/openapi/v2 \
    -g rust \
    -o /local \
    --additional-properties=packageName=kubernetes-client,packageVersion=0.1.0

Steps to reproduce

Related issues/PRs

• [BUG][RUST][CLIENT] Generated enum type used with format! but it doesn't impl Display #16975

Suggest a fix

Perhaps the last part of the URL /{path} or just {path} (not the slash) should be left off if path is None.

[ranger-ross]

Hey there @mickvangelderen

I am assuming you are using this Open API spec provided by Kubernetes.

I was able to reproduce the bug.

As part of /api/v1/nodes/{name}/proxy/{path} there are the follow parameters:

"parameters": [
  {
    "description": "name of the NodeProxyOptions",
    "in": "path",
    "name": "name",
    "required": true,
    "type": "string",
    "uniqueItems": true
  },
  {
    "$ref": "#/parameters/path-z6Ciiujn"
  },
  {
    "$ref": "#/parameters/path-rFDtV0x9"
  }
],

// .....

"path-rFDtV0x9": {
  "description": "Path is the URL path to use for the current proxy request to node.",
  "in": "query",
  "name": "path",
  "type": "string",
  "uniqueItems": true
},
"path-z6Ciiujn": {
  "description": "path to the resource",
  "in": "path",
  "name": "path",
  "required": true,
  "type": "string",
  "uniqueItems": true
},

Interesting, there are 2 parameters for path. (1 path param and 1 query param)
If you put the spec into a viewer like Swagger you can see them.

I believe this is probably what is causing the client generator to get confused.

Looking at the k8s API I am not sure what the difference is, but I think regardless it would be good to make the openapi generator be able to support APIs where there is a path param and query param with the same name

[ranger-ross]

Also I noticed this only happens when using $ref in the parameters block. It works correctly when the parameters are in lined.

Below is a simplified reproducible example

swagger: "2.0"
info:
  description: "This is a sample server Petstore server.  You can find out more about     Swagger at [http://swagger.io](http://swagger.io) or on [irc.freenode.net, #swagger](http://swagger.io/irc/).      For this sample, you can use the api key `special-key` to test the authorization     filters."
  version: "1.0.0"
  title: "Swagger Petstore 2.0"
  termsOfService: "http://swagger.io/terms/"
  contact:
    email: "[email protected]"
  license:
    name: "Apache 2.0"
    url: "http://www.apache.org/licenses/LICENSE-2.0.html"
host: "petstore.swagger.io"
basePath: "/v2"
tags:
- name: "pet"
  description: "Everything about your Pets"
  externalDocs:
    description: "Find out more"
    url: "http://swagger.io"
- name: "store"
  description: "Access to Petstore orders"
- name: "user"
  description: "Operations about user"
  externalDocs:
    description: "Find out more about our store"
    url: "http://swagger.io"
schemes:
- "https"
- "http"
paths:
  /pet/{petId}:
    get:
      tags:
      - "pet"
      summary: "Find pet by ID"
      description: "Returns a single pet"
      operationId: "getPetById"
      produces:
      - "application/xml"
      - "application/json"
      parameters:
      - $ref: '#/parameters/petId1'
      - $ref: '#/parameters/petId2'
      responses:
        "200":
          description: "successful operation"
          schema:
            $ref: "#/definitions/Pet"
        "400":
          description: "Invalid ID supplied"
        "404":
          description: "Pet not found"
definitions:
  Pet:
    type: "object"
    required:
    - "name"
    - "photoUrls"
    properties:
      id:
        type: "integer"
        format: "int64"
    xml:
      name: "Pet"
parameters:
  petId1:
    name: "petId"
    in: "path"
    description: "ID of pet to return"
    required: true
    type: "string"
  petId2:
    name: "petId"
    in: "query"
    description: "ID of pet to return"
    required: false
    type: "string"

[ranger-ross]

Okay after a bit more investigating, the issue appears to be in the swagger-parser.

There is an open issue here: swagger-api/swagger-parser#2102

[ranger-ross]

And this is not a problem with only the Rust clients.

This should be a problem with most languages.