Andrea Cosentino created CAMEL-26543:
----------------------------------------
Summary: camel-huggingface - two chat turns on the same memory ID
at the same time lose one of them, and a CamelChatClearHistory during a turn is
undone
Key: CAMEL-26543
URL: https://issues.apache.org/jira/browse/CAMEL-26543
Project: Camel
Issue Type: Bug
Components: camel-ai
Reporter: Andrea Cosentino
Follow-up of CAMEL-26219 ([PR
#29066|https://github.com/apache/camel/pull/29066]), raised in its review. The
behaviour was there before that change.
The chat task reads the history of the memory ID in {{prepareInput}} and writes
it back, with the new turn, in {{processOutput}} ({{ChatPredictor}} on main
8bd7c2ed53b7: read at line 131, written at line 207).
{{AbstractTaskPredictor.predict}} calls {{prepareInput}} before it takes the
predictor lock (lines 152 and 154), and without pooling there is no lock at all
(lines 166-167). The producer shares one predictor per endpoint.
When two turns on the same memory ID are both prepared before either is
processed:
* each sends the model the history without the other turn, and
* the history written last replaces the other one, so one turn is lost.
A {{CamelChatClearHistory}} request handled while a turn is running (lines
125-127) is undone when that turn writes the old history back with its reply.
Proposed: serialize the turns of one memory ID, for example with a lock per
memory ID held from reading the history to writing it back (bounded like the
history cache), or merge the new messages into the current history when writing
it back. A test with two concurrent turns on one memory ID would pin it down.
_Claude Code on behalf of Andrea Cosentino (oscerd)_
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
