Skip to content

fix: handle consecutive same-role messages with string content#2225

Open
fanxing11 wants to merge 1 commit intohuggingface:mainfrom
fanxing11:fix/consecutive-system-messages-1972
Open

fix: handle consecutive same-role messages with string content#2225
fanxing11 wants to merge 1 commit intohuggingface:mainfrom
fanxing11:fix/consecutive-system-messages-1972

Conversation

@fanxing11
Copy link
Copy Markdown

Fixes #1972

What broke

get_clean_message_list raised AssertionError when two consecutive messages had the same role and the second one had plain string content:

messages = [
    {"role": "system", "content": "Start with FOO"},
    {"role": "system", "content": "End with BAR"},  # crashes here
    {"role": "user",   "content": "Say hi"},
]
AssertionError: Error: wrong content: End with BAR

Root cause

When merging consecutive same-role messages, the code assumed message.content was already a list:

assert isinstance(message.content, list), "Error: wrong content:" + str(message.content)

But ChatMessage.from_dict normalises string content to list format only for the first message added to output_message_list. A follow-up message with the same role goes through a different path that never did that conversion.

Fix

Normalise string content to [{"type": "text", "text": ..}] before merging, same as the rest of the function already does. Three lines changed, no behaviour change for the existing list-content path.

get_clean_message_list crashed with AssertionError when merging
consecutive messages of the same role if content was a plain string.

The previous assert assumed content is always list-format, but string
content is valid (e.g. system messages as dicts with string content).

Fix: normalise string content to list format before merging, matching
the same format used everywhere else in the function.

Fixes huggingface#1972
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

BUG: LiteLLMModel crashes when multiple consecutive system messages are provided

2 participants