[BUG] `List<String>` not bound correctly in x-www-form-urlencoded POST requests (JavaSpring generator)

[bjansen]

Bug Report Checklist

• [x] Have you provided a full/minimal spec to reproduce the issue?
• [ ] Have you validated the input using an OpenAPI validator (example)?
• [x] Have you tested with the latest master to confirm the issue still exists?
• [x] 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

Since #14449 was fixed, List<String> parameters are not mapped correctly in application/x-www-form-urlencoded requests (the controller receives a null value). @RequestPart does not work, but @RequestParam did.

openapi-generator version

6.4.0 (worked fine in 6.2.1).

OpenAPI declaration file content or url

See reproducer here: https://github.com/bjansen/openapi-generator/commit/a4f52bc0fd032b458b4e614eed74e19e761bcb21#diff-4a3bd04de4c3c2657007483855f41966b5bfc3336abacdc74e13ff838341173b

Relevant spec section:

paths:
  /issue:
    post:
      operationId: reproduceIssue
      consumes:
        - application/x-www-form-urlencoded
      parameters:
        - in: body
          name: body
          schema:
            type: "object"
            properties:
              listOfStrings:
                type: "array"
                items:
                  type: "string"
      responses:
        '200':
          description: successful operation

Generation Details

./bin/generate-samples.sh ./bin/configs/spring-boot.yaml generates this mapping:

    default ResponseEntity<Void> reproduceIssue(
        @ApiParam(value = "") @Valid @RequestPart(value = "listOfStrings", required = false) List<String> listOfStrings
    ) {
...

The @RequestPart annotation does not bind the list correctly (see test in OpenApiGeneratorApplicationTests of the spring-boot server sample.

Steps to reproduce

Related issues/PRs

Suggest a fix

[wing328]

@bjansen thanks for reporting the issue. May I know if you can also perform a git bisect to identify the commit that causes the issue?

[bjansen]

Looks like this one: https://github.com/OpenAPITools/openapi-generator/commit/4cd080762aa4c41d7d83fe7c4cb9d28507038f5d (although I didn't do a bisect)

[wing328]

@bjansen thanks.

@MetroMarv I wonder if you can take a look at this issue when you've time to see if it's caused by https://github.com/OpenAPITools/openapi-generator/commit/4cd080762aa4c41d7d83fe7c4cb9d28507038f5d

[tofi86]

It's indeed caused by 4cd0807, but I'd say this is the correct method to fix #14449 (the multipart issue).

However, it looks like the fix introduced a regression with request parameters as mentioned in the above example of this issue. No multipart involved here...