[
https://issues.apache.org/jira/browse/CAMEL-23955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Federico Mariani updated CAMEL-23955:
-------------------------------------
Attachment: OpenAIConversationMemoryUserMessageTest.java
> camel-openai: conversation memory never persists user turns and the
> systemMessage reset is a no-op
> --------------------------------------------------------------------------------------------------
>
> Key: CAMEL-23955
> URL: https://issues.apache.org/jira/browse/CAMEL-23955
> Project: Camel
> Issue Type: Bug
> Components: camel-openai
> Affects Versions: 4.21.0
> Reporter: Federico Mariani
> Priority: Major
> Labels: ai
> Attachments: OpenAIConversationMemoryResetTest.java,
> OpenAIConversationMemoryUserMessageTest.java
>
>
> Two defects in the {{conversationMemory}} feature of the chat-completion
> operation, both present since the component was introduced (commit
> ac0b0e87f26a, CAMEL-22661).
> h3. 1. User turns are never stored in the conversation history
> {{OpenAIProducer.updateConversationHistory}} (all three overloads, around
> lines 663-751) only appends the *assistant* response to the
> {{CamelOpenAIConversationHistory}} exchange property. The user message that
> produced that response is never added. On the next call the model therefore
> sees assistant answers without the user questions that produced them.
> Captured request of the second turn from the attached reproducer
> ({{OpenAIConversationMemoryUserMessageTest}}):
> {code}
> {"messages":[{"role":"assistant","content":"Nice to meet you!"},
> {"content":"What is my name?","role":"user"}],"model":"gpt-5"}
> {code}
> The first user turn ("My name is Alice") is missing, contradicting the
> documented example in {{openai-component.adoc}} ("Conversation Memory (Per
> Exchange)": the second response "Will remember Alice").
> {{OpenAIToolExecutionProducer}} even works around this bug by re-adding the
> user message from the hard-coded {{originalPrompt}} exchange property —
> evidence the history is known to be incomplete.
> The agentic MCP path has the same defect: {{agenticMessages}} contains
> assistant/tool messages but not the triggering user message.
> h3. 2. The documented history reset removes a header instead of the exchange
> property
> {{OpenAIProducer.buildMessages}} (lines 210-214):
> {code:java}
> // If a system message is configured and conversation memory is enabled,
> reset history
> if (ObjectHelper.isNotEmpty(config.getSystemMessage()) &&
> config.isConversationMemory()) {
> in.removeHeader(config.getConversationHistoryProperty());
> }
> {code}
> The conversation history is stored in an exchange *property*
> ({{addConversationHistory}} reads it via {{getExchange().getProperty(...)}}),
> so {{removeHeader}} never removes anything and stale history keeps being
> sent. This contradicts the option documentation ("When set and
> conversationMemory is enabled, the conversation history is reset") and
> {{openai-mcp.adoc}}. Reproducer: {{OpenAIConversationMemoryResetTest}} — the
> stale entry is still present in the captured request.
> h3. Suggested fix
> * Append the outgoing user message (and system/developer messages on the
> first turn, if desired) to the history in {{updateConversationHistory}}, for
> both the simple and the agentic paths.
> * Replace {{in.removeHeader(...)}} with {{exchange.removeProperty(...)}} — or
> reconsider whether the reset-on-systemMessage semantics make sense at all now
> that it never worked (nobody can have depended on it); if kept, document that
> it clears history on *every* call while {{systemMessage}} is set.
> Both reproducer tests are attached; they assert the documented behavior and
> fail on current main. Related: CAMEL-23394 (history size management) should
> be built on top of a corrected history.
> _This issue was drafted by Claude Code on behalf of Federico Mariani_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
