Quarkus LangChain4j ChatMemoryProvider silently leaks into AgentWithoutMemory when default model is configured

[jamesnetherton]

Description

When Quarkus LangChain4j (QL4J) is on the classpath and a default ChatModel is configured via quarkus.langchain4j.* properties, QL4J's ChatMemoryProvider silently leaks into Camel's AgentWithoutMemory, making it stateful despite the user's explicit intent for stateless behavior.

Root Cause

QL4J replaces AiServices.builder() via SPI (AiServicesFactory) in JVM mode and via GraalVM @Substitute in native mode. When Camel calls AiServices.builder(AiAgentWithoutMemoryService.class):

1. QL4J's AiServicesProcessor.determinedImpliedRegisterAiService() discovers AiAgentWithoutMemoryService because it has @UserMessage and @SystemMessage annotations. The AGENTIC_PACKAGE_PREFIX exclusion (dev.langchain4j.agentic.*) does not match Camel's package (org.apache.camel.component.langchain4j.agent.api).

2. QL4J creates a synthetic QuarkusAiServiceContext CDI bean for this interface. Since no explicit chatMemoryProviderSupplier is set on the implied registration, it defaults to BEAN_CHAT_MEMORY_PROVIDER_SUPPLIER — meaning "inject ChatMemoryProvider from CDI."

3. ChatMemoryProcessor always creates a default @ApplicationScoped ChatMemoryProvider (MessageWindowChatMemory). This gets injected into the synthetic context.

4. QuarkusAiServiceContextFactory.create() returns this pre-configured context (with ChatMemoryProvider already set) to Camel's builder.

5. Camel's AgentWithoutMemory.createAiAgentService() only calls .chatModel(config.getChatModel()) — it never resets chatMemoryProvider. The QL4J-injected ChatMemoryProvider survives into the built proxy.

Impact

Since AiAgentWithoutMemoryService has no @MemoryId parameter, the memory ID falls back to either a request-scope hash (HTTP routes) or the literal string "default" (non-HTTP routes like timer, file, kafka). This causes:

• Non-HTTP routes: All AgentWithoutMemory instances across the application share a single global chat memory. Messages from unrelated conversations contaminate each other.
• HTTP routes: Per-request isolation, but InMemoryChatMemoryStore entries are never evicted (memory leak).
• All routes: Each call sends up to 9 prior unrelated messages to the LLM (default window size = 10), increasing token cost, latency, and producing incorrect responses.

No error or warning is logged. The agent silently behaves differently than its name and contract imply.

Steps to Reproduce

1. Add quarkus-langchain4j-ollama (or another QL4J model provider) as a dependency
2. Configure a default model:

   quarkus.langchain4j.ollama.base-url=http://localhost:11434
   quarkus.langchain4j.ollama.chat-model.model-id=llama3.2

3. Create an AgentWithoutMemory with a Camel-managed ChatModel:

   new AgentWithoutMemory(new AgentConfiguration().withChatModel(chatModel))

4. Send multiple unrelated messages through the agent
5. Observe that responses reference content from previous, unrelated messages

Expected Behavior

AgentWithoutMemory should be stateless — each call processed independently with no conversation history, regardless of whether QL4J is on the classpath.

Why Current Tests Don't Catch This

The langchain4j-agent-ql4j integration test uses @Identifier-qualified ChatModel beans and does not configure a default QL4J model via properties. Without a default ChatModel, the CDI context bean creation fails and QuarkusAiServiceContextFactory falls back to a clean empty context. The ChatMemoryProvider doesn't leak — but only by accident, not by design.

Additional Context

The langchain4j-agent-ql4j test README acknowledges related interference: RetrievalAugmentor had to be disabled (cq-test.retrieval.augmentor.disabled=true) because "Testing with quarkus-langchain4j does not work when the RetrievalAugmentor bean is present with scope ."

[jamesnetherton]

Some potential options to fix this (in order of complexity):

1. Set AiServiceContext.chatMemoryService field to null directly when AiAgentWithoutMemoryService is created.

AiServiceContext ctx = AiServiceContext.create(AiAgentWithoutMemoryService.class);
ctx.chatMemoryService = null;
AiServices.<AiAgentWithoutMemoryService>builder(ctx).chatModel(...).build();

This works, but relies on @Internal APIs (QL4J actually uses these classes directly already).

2. Fix LangChain4j

Make chatMemoryProvider(null) on that AiServices builder actually clear memory instead of ignoring null. E.g remove null guard here:

https://github.com/langchain4j/langchain4j/blob/c2aa57844eb1974572f9c9d12e6a74566d2a57f6/langchain4j/src/main/java/dev/langchain4j/service/AiServices.java#L431-L433

Then the chatMemoryProvider could be nullified in AgentWithoutMemory.createAiAgentService.

3. Fix QL4J add and an exclusion mechanism where the Camel agent interfaces could be excluded from build time discovery.

E.g by providing a build item with a predicate that matches against a FQCN. Similar to how IgnoreJaxbAnnotatedClassesBuildItem works.

[JiriOndrusek]

I went with option 3, which seems to me as the best alternative.
The ql4j PR is proposed here: quarkiverse/quarkus-langchain4j#2722

[JiriOndrusek]

The problem is more complicated then I thought. The fix in ql4j makes the scenario correctly pass , but somehow returns issue quarkiverse/quarkus-langchain4j#2344 to some other tests. I need to dig into it.

[JiriOndrusek]

another PRs was proposed:

• Replace NoopChatMemory with LocalCommittableChatMemory quarkiverse/quarkus-langchain4j#2725