fix: normalize content to "" instead of dropping it for assistant too…#4003
fix: normalize content to "" instead of dropping it for assistant too…#4003kanxiao wants to merge 3 commits into
Conversation
…l-call messages Some LLMs (e.g. Gause) return HTTP 422 when an assistant message has tool_calls and content=null. Previously _remove_content_if_empty() dropped the content key entirely, which produced content=null in the serialized payload. Now it sets content="" instead, matching the behavior that _normalize_empty_assistant_content() already uses for non-tool-call messages.
|
[Automatic Post]: It has been a while since there was any activity on this PR. @kanxiao, are you still working on it? If so, please go ahead, if not then please request review, close it, or request that someone else follow up. This comment was posted by an AI agent (OpenHands) on behalf of the user. |
|
[Automatic Post]: It has been a while since there was any activity on this PR. @kanxiao, are you still working on it? If so, please go ahead, if not then please request review, close it, or request that someone else follow up. This comment was created by an AI agent (OpenHands) on behalf of the user. |
|
[Automatic Post]: I have assigned @enyst as a reviewer based on the repository MAINTAINERS file. Thanks in advance for the help! This comment was created by an AI agent (OpenHands) on behalf of the repository maintainers. |
HUMAN:
Fix assistant tool-call messages returning HTTP 422 on some LLMs due to content=null.
AGENT:
Why
Some LLMs (e.g. Gause) return HTTP 422 when an assistant message has
tool_callsandcontent=null. The_remove_content_if_empty()method was dropping thecontentkey entirely, producingcontent=nullin the serialized payload. Some providers requirecontentto be present (even if empty string).Summary
_remove_content_if_empty()to setcontent=""instead ofmessage_dict.pop("content", None), in both the string and list content branches.result["content"] == ""instead ofassert "content" not in result.Issue Number
N/A
How to Test
Expected: all 5 tests pass, and assistant messages with tool_calls + empty content now serialize as {"role": "assistant", "content": "", "tool_calls": [...]} instead of having the content key absent.
Video/Screenshots
N/A
Type
Notes
This is consistent with the existing _normalize_empty_assistant_content() behavior which already sets content="" for non-tool-call assistant messages. The change only affects the wire format sent to LLM providers — internal Message objects are unchanged.