Skip to content

Conversation

@Picazsoo
Copy link
Contributor

@Picazsoo Picazsoo commented Feb 9, 2026

This change updates the generator to correctly map OpenAPI format: byte fields across all locations.

  • Query, Path, Header, Cookie, and Form fields: format: byte is generated as String (manual Base64 decoding required).
  • Multipart text fields: String.
  • Multipart file fields (format: binary): MultipartFile.
  • JSON request body DTO fields: byte[], with automatic Base64 decoding via Jackson.
  • Raw binary request bodies (application/octet-stream): Resource for streaming, no decoding applied.

This ensures all format: byte values are correctly typed across parameters and bodies, preserving the distinction between Base64-encoded values and raw binary.

The changes are practically limited to QueryParam; PathParam; HeaderParam; CookieParam; FormParam. But all the other types are asserted as well to prevent accidental regression.

fixes #22898

Tests performed:

Verified generated Java files for query, path, header, cookie, form, multipart, JSON body, and binary body fields.

Asserts confirm parameters and properties have the expected types (String, byte[], MultipartFile, Resource).

PR checklist

  • Read the contribution guidelines.
  • Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
  • Run the following to build the project and update samples:
    ./mvnw clean package || exit
    ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
    ./bin/utils/export_docs_generators.sh || exit
    
    (For Windows users, please run the script in WSL)
    Commit all changed files.
    This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
    These must match the expectations made by your contribution.
    You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
    IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
  • File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
  • If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
  • If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request. - tagging: @cachescrubber (2022/02) @welshm (2022/02) @MelleD (2022/02) @atextor (2022/02) @manedev79 (2022/02) @javisst (2022/02) @borsch (2022/02) @Zomzog (2022/09) @martin-mfg (2023/08)

Summary by cubic

Convert byte[] operation parameters to String in the Java Spring generator for query, path, header, cookie, and form params. Spring doesn’t auto-decode base64 for these, so we now accept the raw base64 string to prevent type issues.

  • Bug Fixes

    • Map byte[] params in query/path/header/cookie/form to String in SpringCodegen; JavaSpring templates add “base64 encoded binary” comments.
    • Keep ByteArray → byte[] for models and JSON request bodies; raw binary bodies remain Resource; multipart binary fields use MultipartFile. Added explicit ByteArray → byte[] mapping in AbstractJavaCodegen.
    • Added tests with a focused OAS fixture (byte-format-edge-cases.yaml) covering params, DTO properties, multipart fields, JSON bodies, and binary bodies; minor spec cleanup.
  • Migration

    • If you previously used byte[] for these params, decode the provided base64 String yourself (e.g., Base64.getDecoder().decode(value)).

Written for commit 02a530a. Summary will update on new commits.

@Picazsoo Picazsoo marked this pull request as ready for review February 9, 2026 22:51
Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 issues found across 41 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="samples/server/petstore/springboot-reactive-noResponseEntity/src/main/java/org/openapitools/api/FakeApi.java">

<violation number="1" location="samples/server/petstore/springboot-reactive-noResponseEntity/src/main/java/org/openapitools/api/FakeApi.java:383">
P2: @RequestPart is for multipart/form-data, but this endpoint consumes application/x-www-form-urlencoded. The modified parameter still uses @RequestPart, so WebFlux won’t bind the form body correctly (likely 400).</violation>
</file>

<file name="modules/openapi-generator/src/test/java/org/openapitools/codegen/java/spring/SpringCodegenTest.java">

<violation number="1" location="modules/openapi-generator/src/test/java/org/openapitools/codegen/java/spring/SpringCodegenTest.java:944">
P2: Form/multipart DTO still asserts `format: byte` as `byte[]`, but Spring’s default data binding does not Base64‑decode form strings to `byte[]`; it converts the string to raw bytes. This makes form DTO binding inconsistent with the new `String` parameter handling and can yield incorrect values without a custom converter.</violation>
</file>

Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.

@ApiParam(value = "None", required = true) @DecimalMin(value = "67.8") @DecimalMax(value = "123.4") @Valid @RequestPart(value = "double", required = true) Double _double,
@ApiParam(value = "None", required = true) @Pattern(regexp = "^[A-Z].*") @Valid @RequestPart(value = "pattern_without_delimiter", required = true) String patternWithoutDelimiter,
@ApiParam(value = "None", required = true) @Valid @RequestPart(value = "byte", required = true) byte[] _byte,
@ApiParam(value = "None", required = true) @Valid @RequestPart(value = "byte", required = true) String _byte /* base64 encoded binary */,
Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: @RequestPart is for multipart/form-data, but this endpoint consumes application/x-www-form-urlencoded. The modified parameter still uses @RequestPart, so WebFlux won’t bind the form body correctly (likely 400).

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At samples/server/petstore/springboot-reactive-noResponseEntity/src/main/java/org/openapitools/api/FakeApi.java, line 383:

<comment>@RequestPart is for multipart/form-data, but this endpoint consumes application/x-www-form-urlencoded. The modified parameter still uses @RequestPart, so WebFlux won’t bind the form body correctly (likely 400).</comment>

<file context>
@@ -380,7 +380,7 @@ default Mono<Void> testEndpointParameters(
         @ApiParam(value = "None", required = true) @DecimalMin(value = "67.8") @DecimalMax(value = "123.4") @Valid @RequestPart(value = "double", required = true) Double _double,
         @ApiParam(value = "None", required = true) @Pattern(regexp = "^[A-Z].*") @Valid @RequestPart(value = "pattern_without_delimiter", required = true) String patternWithoutDelimiter,
-        @ApiParam(value = "None", required = true) @Valid @RequestPart(value = "byte", required = true) byte[] _byte,
+        @ApiParam(value = "None", required = true) @Valid @RequestPart(value = "byte", required = true) String _byte /* base64 encoded binary */,
         @ApiParam(value = "None") @Min(value = 10) @Max(value = 100) @Valid @RequestPart(value = "integer", required = false) Integer integer,
         @ApiParam(value = "None") @Min(value = 20) @Max(value = 200) @Valid @RequestPart(value = "int32", required = false) Integer int32,
</file context>
Fix with Cubic

JavaFileAssert.assertThat(files.get("FormParamsRequest.java"))
.assertProperty("_byte")
.isArray()
.withType("byte"); // Base64 property in DTO → auto-decoded to byte[]
Copy link
Contributor

@cubic-dev-ai cubic-dev-ai bot Feb 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2: Form/multipart DTO still asserts format: byte as byte[], but Spring’s default data binding does not Base64‑decode form strings to byte[]; it converts the string to raw bytes. This makes form DTO binding inconsistent with the new String parameter handling and can yield incorrect values without a custom converter.

Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At modules/openapi-generator/src/test/java/org/openapitools/codegen/java/spring/SpringCodegenTest.java, line 944:

<comment>Form/multipart DTO still asserts `format: byte` as `byte[]`, but Spring’s default data binding does not Base64‑decode form strings to `byte[]`; it converts the string to raw bytes. This makes form DTO binding inconsistent with the new `String` parameter handling and can yield incorrect values without a custom converter.</comment>

<file context>
@@ -864,6 +864,92 @@ public void testSchemaImplements() throws IOException {
+        JavaFileAssert.assertThat(files.get("FormParamsRequest.java"))
+                .assertProperty("_byte")
+                .isArray()
+                .withType("byte");  // Base64 property in DTO → auto-decoded to byte[]
+
+        // Binary request body: bound as Resource for streaming
</file context>
Fix with Cubic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG][SPRING] Incorrect handling of format: byte in query strings

1 participant