Croway commented on PR #29542: URL: https://github.com/apache/camel/pull/29542#issuecomment-6765667557
Thanks for the fix. I reproduced it: `AbstractWatsonxAiHandlerFileNameTest.usesTheAzureBlobName` fails against `main` with `File name must be provided via header 'CamelIBMWatsonxAiFileName' when using InputStream input`, and passes with this PR. No changes needed here. A non-blocking note for a follow-up, not for this PR. Copying another component's header names is how this bug got in: nothing ties the string to `BlobConstants.BLOB_NAME`, so the wrong name went unnoticed from the start. The same pattern is in two more places, which carry the same copied list of 6 storage content-type headers: - `camel-openai`: `MimeTypeHelper.CONTENT_TYPE_HEADERS` - `camel-langchain4j-agent`: `LangChain4jAgentConverter.detectMimeTypeFromHeaders` The list here is also incomplete. With only `CamelIBMCOSKey` (set by `IBMCOSConsumer`) or `CamelMinioObjectName` (set by `MinioEndpoint`) on the message, `resolveFileName` still throws. I checked this with two extra cases in your test. I'll open a JIRA to fix this at the source. The proposal is that the storage consumers also set the core `CamelFileName` and `CamelFileContentType` headers (`google-storage` and `azure-files` already set `CamelFileName`). Then watsonx-ai, openai and langchain4j-agent read only core headers and drop their lists. _Claude Code on behalf of Croway_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
