CAMEL-23205: Fix OpenAI embedding ITs to check exchange exceptions

[gnodet]

Summary

The OpenAI embedding integration tests were failing with ClassCastException not because of the encoding format default, but because:

1. Missing embedding model: When OllamaServiceConfiguration.embeddingModelName() returns null (no embedding model configured), the producer sets an exception on the exchange. The tests then tried to cast the unchanged body to List<Float>, causing a ClassCastException.

2. No exception checking: Tests called template.request() but never checked result.getException() before casting the body.

Changes

• Add Assumptions.assumeTrue(ObjectHelper.isNotEmpty(embeddingModel)) in setupResources() to skip tests when no embedding model is available
• Add assertThat(result.getException()).isNull() after every template.request() call to surface the real error instead of a misleading ClassCastException

Test plan

• Tests skip gracefully when embedding model is not configured
• When embedding model is available, tests pass and properly report any API errors

[gnodet]

Local test run (actual IT execution via mvn verify): ALL 4 TESTS PASSED ✅

[INFO] Running org.apache.camel.component.openai.integration.OpenAIEmbeddingsIT
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.007 s
BUILD SUCCESS

Ran against local Ollama via testcontainers.

[apupier]

this kind of change must be documented in the migration guide

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using build-all, build-dependents, skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• components/camel-ai/camel-openai

Full reactor (72 modules)

• Camel :: AI :: OpenAI
• Camel :: AI :: OpenAI [jar]
• Camel :: All Components Sync point
• Camel :: All Components Sync point [pom]
• Camel :: Assembly
• Camel :: Assembly [pom]
• Camel :: Catalog :: CSimple Maven Plugin (deprecated) [maven-plugin]
• Camel :: Catalog :: CSimple Maven Plugin (deprecated) SUCCESS [ 1.403 s]
• Camel :: Catalog :: Camel Catalog
• Camel :: Catalog :: Camel Catalog [jar]
• Camel :: Catalog :: Camel Report Maven Plugin
• Camel :: Catalog :: Camel Report Maven Plugin [maven-plugin]
• Camel :: Catalog :: Camel Route Parser
• Camel :: Catalog :: Camel Route Parser [jar]
• Camel :: Catalog :: Console
• Camel :: Catalog :: Console [jar]
• Camel :: Catalog :: Dummy Component
• Camel :: Catalog :: Dummy Component [jar]
• Camel :: Catalog :: Lucene (deprecated)
• Camel :: Catalog :: Lucene (deprecated) [jar]
• Camel :: Catalog :: Maven
• Camel :: Catalog :: Maven [jar]
• Camel :: Catalog :: Suggest
• Camel :: Catalog :: Suggest [jar]
• Camel :: Component DSL
• Camel :: Component DSL [jar]
• Camel :: Coverage
• Camel :: Coverage [pom]
• Camel :: Docs
• Camel :: Docs [pom]
• Camel :: Endpoint DSL
• Camel :: Endpoint DSL [jar]
• Camel :: Endpoint DSL :: Support
• Camel :: Endpoint DSL :: Support [jar]
• Camel :: Integration Tests
• Camel :: Integration Tests [jar]
• Camel :: JBang :: Core
• Camel :: JBang :: Core [jar]
• Camel :: JBang :: Integration tests
• Camel :: JBang :: Integration tests [jar]
• Camel :: JBang :: MCP
• Camel :: JBang :: MCP [jar]
• Camel :: JBang :: Main
• Camel :: JBang :: Main [jar]
• Camel :: JBang :: Plugin :: Edit
• Camel :: JBang :: Plugin :: Edit [jar]
• Camel :: JBang :: Plugin :: Generate
• Camel :: JBang :: Plugin :: Generate [jar]
• Camel :: JBang :: Plugin :: Kubernetes
• Camel :: JBang :: Plugin :: Kubernetes [jar]
• Camel :: JBang :: Plugin :: Route Parser
• Camel :: JBang :: Plugin :: Route Parser [jar]
• Camel :: JBang :: Plugin :: Testing
• Camel :: JBang :: Plugin :: Testing [jar]
• Camel :: JBang :: Plugin :: Validate
• Camel :: JBang :: Plugin :: Validate [jar]
• Camel :: Kamelet Main
• Camel :: Kamelet Main [jar]
• Camel :: Launcher
• Camel :: Launcher [jar]
• Camel :: Launcher :: Container
• Camel :: Launcher :: Container [pom]
• Camel :: YAML DSL
• Camel :: YAML DSL [jar]
• Camel :: YAML DSL :: Deserializers
• Camel :: YAML DSL :: Deserializers [jar]
• Camel :: YAML DSL :: Maven Plugins
• Camel :: YAML DSL :: Maven Plugins [maven-plugin]
• Camel :: YAML DSL :: Validator
• Camel :: YAML DSL :: Validator [jar]
• Camel :: YAML DSL :: Validator Maven Plugin
• Camel :: YAML DSL :: Validator Maven Plugin [maven-plugin]

[jamesnetherton]

Not sure I understand the issue with CAMEL-23205.

If you want to run tests that include embeddings, then it should be mandatory to specify an embedding model, no? I don't get how changing the default encoding format fixes anything.

[gnodet]

@jamesnetherton The embedding model is specified — it comes from the Ollama test service via OLLAMA.embeddingModelName() (see setupResources() in the test). That part works fine.

The issue is the encodingFormat parameter. The OpenAI embeddings API supports two formats:

• float: returns embedding vectors as List<Float>
• base64: returns embedding vectors as a base64-encoded string

The producer code at OpenAIEmbeddingsProducer.java:109 calls embedding.embedding() which returns List<Float>. This works when the format is float, but when it's base64, the API returns a different data structure (base64 string), and the SDK's embedding.embedding() call results in a ClassCastException because it tries to deserialize a base64 string as a float list.

The default was base64, so the direct:embedding route (which uses defaults, no explicit encodingFormat) would always fail. The direct:embeddingWithEncodingFormatFloat route worked because it explicitly set encodingFormat=float.

Changing the default to float aligns the default with what the producer code actually expects. If someone wants base64, they'd need to set it explicitly and handle the response format differently.

[jamesnetherton]

@jamesnetherton The embedding model is specified — it comes from the Ollama test service via OLLAMA.embeddingModelName() (see setupResources() in the test). That part works fine.

The issue is the encodingFormat parameter. The OpenAI embeddings API supports two formats:

• float: returns embedding vectors as List<Float>
• base64: returns embedding vectors as a base64-encoded string

The producer code at OpenAIEmbeddingsProducer.java:109 calls embedding.embedding() which returns List<Float>. This works when the format is float, but when it's base64, the API returns a different data structure (base64 string), and the SDK's embedding.embedding() call results in a ClassCastException because it tries to deserialize a base64 string as a float list.

The default was base64, so the direct:embedding route (which uses defaults, no explicit encodingFormat) would always fail. The direct:embeddingWithEncodingFormatFloat route worked because it explicitly set encodingFormat=float.

Changing the default to float aligns the default with what the producer code actually expects. If someone wants base64, they'd need to set it explicitly and handle the response format differently.

Take another look at https://issues.apache.org/jira/browse/CAMEL-23205. The problem was the that no embedding model was specified.

The tests aren't checking whether the Exchange result returned from template.request has an exception set, due to the missing model (see OpenAIEmbeddingsProducer line 70) . So they proceed to try and cast the exchange body to List<Float>. If an exception is thrown, the body will just be the original 'in' String message. Hence ClassCastException.

It's not related to encoding format. openai-java is smart enough to decode base64 content to List<Float>. See com.openai.models.embeddings.EmbeddingValue.asFloats().

[gnodet]

@jamesnetherton You're absolutely right — I was wrong about the encoding format being the root cause. The openai-java SDK handles base64→float conversion via EmbeddingValue.asFloats(), so the default encoding format is irrelevant to the ClassCastException.

The real issue was:

1. The Ollama test container doesn't provide an embedding model by default (embeddingModelName() returns null)
2. This causes the producer to set an exception on the exchange
3. The tests never checked result.getException() and tried to cast the body directly, leading to a misleading ClassCastException

I've reworked the PR to:

• Revert the encoding format default back to base64
• Add Assumptions.assumeTrue to skip tests when no embedding model is available
• Add exception assertions after each template.request() call

Thanks for catching this!

[jamesnetherton]

The Ollama test container doesn't provide an embedding model by default (embeddingModelName() returns null)

Not true. The Ollama test-infra provides this. The default is granite-embedding:30m.

Add Assumptions.assumeTrue to skip tests when no embedding model is available

Maybe not what we want. Not sure what other folks think, but it might be better to 'fail fast' in setupResources or createCamelContext if embeddingModel is null.

[gnodet]

@jamesnetherton You're right that the container infra provides granite-embedding:30m by default (via container.properties). The issue only manifests with the remote infra (-Dollama.instance.type=remote), which reads from System.getProperty(OllamaProperties.EMBEDDING_MODEL) with no fallback default. The JIRA reporter was running:

mvn verify -Dollama.endpoint=http://localhost:11434/ -Dollama.model=granite4:3b -Dollama.instance.type=remote

...without specifying -Dollama.embedding.model=..., so embeddingModelName() returned null.

I agree that Assumptions.assumeTrue is not ideal here. I'll rework the PR to:

1. Remove the assumption guard
2. Keep the exception assertions (those are genuinely useful regardless — the ClassCastException was very confusing)
3. Fail fast in setupResources if the embedding model is null, as you suggested

Alternatively, we could also fix OllamaRemoteInfraService to fall back to container.properties defaults (like the container infra does), but that's a separate concern.