fix(ai): a retried LLM chat task should keep its conversation history

[ling-senpeng13]

The bug

Retrying an LLM_CHAT_COMPLETE task in an agent workflow loses the entire conversation. The retried attempt sees only the static [system, user] template from the workflow definition, not the history the first attempt had.

Why it happens

Conversation history is never expressed as a ${...} reference in the workflow definition. AgentChatCompleteTaskMapper assembles it imperatively in Java at scheduling time — walking the workflow's completed tasks, extracting tool results, condensing if the context window demands it — and writes the result into the task's inputData.

Retry doesn't re-run the mapper. It copies the task and re-resolves the definition:

TaskModel taskToBeRetried = task.copy();              // history is here...
taskToBeRetried.getInputData().putAll(taskInput);     // ...and clobbered by re-resolving
                                                      //    the definition's inputParameters

Since the definition's inputParameters contain only the static template, putAll overwrites the assembled conversation with it. The history existed solely in the first attempt's inputData, and that's what gets replaced.

Fix

The mapper strips messages and tools from the task's own copy of the definition before it's persisted, so at retry time getWorkflowTask().getInputParameters() doesn't have them, the re-resolved taskInput in taskToBeRescheduled() doesn't have them, and putAll can't overwrite the assembled values which is the root cause of this bug.

AIModelTaskMapper#detachAssembledInputFromDefinition(TaskModel, String... keys), shared by both chat-complete mappers.

Testing

• groovy test
• It is covered in Add e2e suite 27: retried LLM turn must keep conversation history python-sdk#462. Verified in the local environment before the test PR is merged.

[manan164]

Does this happen with all worker task that we lose input parameters on retry?

[ling-senpeng13]

Does this happen with all worker task that we lose input parameters on retry?

Yes — re-resolving inputParameters on retry is the designed behaviour for every worker task, not
something specific to LLM tasks:

taskToBeRetried.getInputData().putAll(taskInput);   // taskToBeRescheduled

[NicholasDCole]

Couple suggestions. Please check