`oneOf` in path params is causing validation errors when using OAS 3.0

[adamsosterics]

I have the following spec:

openapi: 3.0.1
paths:
  /accounts/{id}:
    get:
      operationId: getAccountId
      summary: Get the details of an account
      parameters:
        - name: id
          in: path
          required: true
          schema:
            oneOf:
              - type: integer
              - type: string
                enum: [current]

When validating e.g. GET /accounts/1 request, I get an Path segment is invalid: value at '/id' is not an integer. value at '/id' is not one of: ["current"] error.
The following schema for the path parameter already reproduces the issue:

oneOf:
  - type: integer

The following schema does not give a validation error:

type: integer

The parsed_request in /lib/openapi_first/validators/request_parameters.rb:15 in the case of a schema using oneOf:
#<data OpenapiFirst::ParsedRequest path={"id"=>"1"}, ...>, without oneOf: #<data OpenapiFirst::ParsedRequest path={"id"=>1}, ...>, that could cause the path param to be invalid.

I believe the spec above using the schema with the oneOf is valid and should not give validation errors for requests like GET /accounts/1.

[ahx]

Hi

this is probably because openapi_parameters does not know how to convert the path parameter value, because it can be a string or an integer.

I suggest updating to OpenAPI 3.1, which supports format: number and changing the parameter definition to something like this:

oneOf:
              - type: string
                format: number
              - type: string
                enum: [current]

It might be possible to add support for this in openapi_parameters, but I think using the workaround is actually the better option.

[ahx]

@adamsosterics Any thoughts about this?

[adamsosterics]

We actually want to upgrade to OAS 3.1, that's why we are experimenting with your gem, but we need everything working in 3.0 first.
However, the design of this particular operation is not great, we are going to refactor it, so we won't need a parameter that's either an integer or a string.
Thank you anyway!

[ahx]

Cool. If you have any thoughts about if or how the gem should somehow make people aware of these restrictions don't hesitate to share your thoughts.