Skip to content

fix: [OpenAPI] Pin file upload parameter to File type#1160

Open
rpanackal wants to merge 3 commits intomainfrom
fix/openapi/file-import
Open

fix: [OpenAPI] Pin file upload parameter to File type#1160
rpanackal wants to merge 3 commits intomainfrom
fix/openapi/file-import

Conversation

@rpanackal
Copy link
Copy Markdown
Member

@rpanackal rpanackal commented Apr 27, 2026

Context

On file uploads, the remote service may expect (here Prompt Registry) Content-Disposition header to contain the filename. At the moment, setting <typeMappings>File=byte[]<typeMappings> can replace all occurrence of File type with byte[].

This means on upload operations, we end up losing filename information, critical for correct successful response.

Feature scope:

  • Pin the parameter type to File in upload operation
    • Unmodifiable with <typeMappings>File=byte[]<typeMappings> override. Now only influence return type on download operations.

This is a breaking change.

Definition of Done

  • Functionality scope stated & covered
  • Tests cover the scope above
  • Error handling created / updated & covered by the tests above
  • Documentation updated
  • Release notes updated

@rpanackal rpanackal changed the title Fix/openapi/file import fix: [OpenAPI] Pin file upload parameter to File type Apr 27, 2026
Copy link
Copy Markdown
Member Author

@rpanackal rpanackal left a comment

Choose a reason for hiding this comment

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

Here is a viable alternate proposal due to the existence of <typeMappings>File=byte[]<typeMappings>

Current: We pin upload type and allows typeMappings to choose download type

Alternate: We pin download type to byte[] and allow typeMappings to override upload type

I don't see a particular winner. So, any ideas are welcomes

Copy link
Copy Markdown
Member Author

@rpanackal rpanackal left a comment

Choose a reason for hiding this comment

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

Why not simply keep upload parameter and download return type as File?

From earlier discussions, we want to avoid placing the expectation on user to handle downloaded files properly.
Related Comment

@rpanackal
Copy link
Copy Markdown
Member Author

rpanackal commented Apr 27, 2026

Here is a viable alternate proposal due to the existence of <typeMappings>File=byte[]<typeMappings>

Current: We pin upload type and allows typeMappings to choose download type

Alternate: We pin download type to byte[] and allow typeMappings to override upload type

I don't see a particular winner. So, any ideas are welcomes

Nevermind. Pinning return type to byte[] in the alternate design is not feasible. There is no available isFile or isReturnFile flag on define a conditional logic in mustache file.

Comment thread release_notes.md
### 🔧 Compatibility Notes

-
- [OpenAPI] In Apache HttpClient generator, file upload parameters are now pinned to type `java.io.File`, unmodifiable with `<typeMappings>` in generator configuration.
Copy link
Copy Markdown
Contributor

@newtork newtork Apr 27, 2026

Choose a reason for hiding this comment

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

(Major/Question)

Are you saying this will no longer have an effect?

(openapi-api-apache-sample/pom.xml)

<typeMappings>File=byte[]</typeMappings>

Sounds like a regression to me.

Copy link
Copy Markdown
Member Author

@rpanackal rpanackal Apr 27, 2026

Choose a reason for hiding this comment

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

Setting <typeMappings> is effective for download operations to change return type from File to byte[]. But not in upload operation.

The default behaviour has always been (is still) File type on method parameter and return type. In prompt registry, we overrid this behaviour using <typeMappings> . So, for our regular user, nothing changes. Still, advanced users are affected.

If that is not acceptable, we will have to go with introducing a new feature flag.

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.

2 participants