Skip to content

fix(models): handle string content when merging consecutive same-role messages#2220

Open
VANDRANKI wants to merge 1 commit intohuggingface:mainfrom
VANDRANKI:fix/litellm-model-consecutive-system-msg
Open

fix(models): handle string content when merging consecutive same-role messages#2220
VANDRANKI wants to merge 1 commit intohuggingface:mainfrom
VANDRANKI:fix/litellm-model-consecutive-system-msg

Conversation

@VANDRANKI
Copy link
Copy Markdown

Summary

get_clean_message_list raises AssertionError when the input contains two or more consecutive messages with the same role (e.g. two system messages) and those messages have plain string content.

Reproducer from issue #1972:

messages = [
    {"role": "system", "content": "Start every reply with FOO"},
    {"role": "system", "content": "End every reply with BAR"},
    {"role": "user", "content": "Say hello"},
]
LiteLLMModel(...)(messages)  # AssertionError

Root cause

ChatMessage.content is str | list[dict] | None. When messages are passed as plain dicts with a string "content" field, from_dict stores content as a str. The merge branch (hit when two consecutive messages share the same role) immediately asserts isinstance(message.content, list) without handling the string case, causing the crash.

Fix

Before attempting the merge, normalize both the incoming message.content and the previously-stored output_message_list[-1]["content"] to [{"type": "text", "text": ...}] if either is a string. The existing list-based merge logic then handles all cases uniformly, and consecutive string-content system messages are concatenated with a newline.

No behavior change for callers that already pass list-format content.

Fixes #1972

… messages

get_clean_message_list merges consecutive messages that share the same role.
The merge path assumed message.content is always a list, but messages passed
as plain dicts with a string "content" field (e.g. system messages like
{"role": "system", "content": "..."}) store content as a str after from_dict.
This caused an AssertionError when two consecutive system messages were in
the input list.

Normalize string content to [{"type": "text", "text": ...}] for both the
incoming message and the previously-appended message before the merge, so
the existing list-based merge logic handles all cases uniformly.

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

1 participant