Array<Long> is not supported in query parameters

[plapinsc]

The following swagger definition:

    /WTF:
    get:
      operationId: "wtf"
      produces:
      - "application/json"
      parameters:
      - name: "id"
        in: "query"
        required: false
        type: "array"
        items:
          type: "integer"
          format: "int64"
        collectionFormat: "multi"
      responses:
        200:
          description: "successful operation"

generates a method with Iterable[String] input parameters instead of Iterable[Long]:
def wtf(respond: Resource.wtfResponse.type)(id: Option[Iterable[String]] = None): scala.concurrent.Future[Resource.wtfResponse]

the expected result is:
def wtf(respond: Resource.wtfResponse.type)(id: Option[Iterable[Long]] = None): scala.concurrent.Future[Resource.wtfResponse]

To quickly mitigate the issue, I wanted to implement it with String and parse long by myself, but:
#184

[plapinsc]

Quick workaround: x-scala-type: "Iterable[Long]" seems to be working...

[rtfpessoa]

@blast-hardcheese if I wanted to fix this where should I start looking?

[blast-hardcheese]

@plapinsc Which version of guardrail was this happening on?

@rtfpessoa Depending on the answer, likely propMeta.

That being said, this got upended in 0.44.0 due to the switch to OpenAPI 3.x; to save yourself some effort, I'd check to make sure this is still broken in master (or with what's in #192, as that'll be reviewed and merged at some point this week).

The easiest way to test this would be to just modify modules/sample/src/main/resources/server1.yaml and run runtimeSuite in sbt, examining the generated result in modules/sample-*

[plapinsc]

Our guardrail version is: 0.43.0

[rtfpessoa]

At least a handful of versions before and including 0.44.0 have this problem.
Will try to check master.

[rtfpessoa]

@blast-hardcheese seems like this still happens in 0.45.1 will try to look at your suggestion when I get some time.

[blast-hardcheese]

Excellent! Feel free to follow up here if things are not going as you expect, I may be able to dig up some more pointers

[rtfpessoa]

@blast-hardcheese tried to look into this today but never had to work with a free codebase and following the flow seems quite hard to grasp.
Do you have any other ideas where it might be loosing the initial read value of ("integer", "int64") to "string"?

The only things I was able to check was that the initial array seems fine, but then when propMeta is invoked the items type change to string somehow.

[blast-hardcheese]

A passable tool for debugging local issues is to ~cli scala --client --specPath modules/sample/src/main/resources/alias.yaml --outputPath modules/sample-akkaHttp/target/generated --packageName alias.client.akkaHttp --framework akka-http in the sbt console, as well as () = println(...) inside for comprehensions to track down where values are doing different things than what you expect.

Narrowing it down to propMeta is not at all surprising, but figuring out exactly what's wrong will require runtime analysis, as it's likely something like ArraySchema { items = ObjectSchema { schema = LongSchema {} } } or similar coming out of the swagger-parser data model that we are not correctly analyzing and representing in our generated code.

[blast-hardcheese]

#1407 resolves this

[blast-hardcheese]

Pardon for the delay here, this is now resolved.