`Qwen3Renderer` silently renders an empty turn when `content` is a list of text parts

[vsimkus]

Qwen3Renderer reads content only when it is already a str and coerces anything else to "", so a message built from OpenAI-style content parts renders as a well-formed but empty turn. Both call sites do it - qwen3.py:215 (render) and qwen3.py:398 (bridge_to_next_turn):

content = msg.get("content") if isinstance(msg.get("content"), str) else ""

Repro

from renderers import Qwen3Renderer
from transformers import AutoTokenizer

messages = [
    {"role": "user", "content": "What is 2+2?"},
    {"role": "assistant", "content": [{"type": "text", "text": "The answer is 4."}]},
]
tok = AutoTokenizer.from_pretrained("Qwen/Qwen3-30B-A3B")
print(repr(tok.decode(Qwen3Renderer(tok).render(messages).token_ids)))

The assistant's text is gone:

'<|im_start|>user\nWhat is 2+2?<|im_end|>\n<|im_start|>assistant\n<think>\n\n</think>\n\n<|im_end|>\n'

Llama3Renderer on the same messages keeps it: ...assistant<|end_header_id|>\n\nThe answer is 4.<|eot_id|>.

Proposed fix

Copy Llama3Renderer._content_str (llama_3.py:136), which already handles str / None / list-of-text-parts and raises on anything else, and replace both coercions with content = self._content_str(msg.get("content")).

[HBX814]

I tried to reproduce this before writing the patch, and I think the premise is worth re-checking: Qwen3Renderer looks like it's faithfully mirroring the Qwen3 chat template here rather than diverging from it.

The upstream template does the same coercion (Qwen/Qwen3-30B-A3B, tokenizer_config.json):

{%- if message.content is string %}
    {%- set content = message.content %}
{%- else %}
    {%- set content = '' %}
{%- endif %}

So on your exact repro, the renderer and apply_chat_template agree byte-for-byte:

RENDERER : '<|im_start|>user\nWhat is 2+2?<|im_end|>\n<|im_start|>assistant\n<think>\n\n</think>\n\n<|im_end|>\n'
TEMPLATE : '<|im_start|>user\nWhat is 2+2?<|im_end|>\n<|im_start|>assistant\n<think>\n\n</think>\n\n<|im_end|>\n'
IDENTICAL: True

The empty turn is what Qwen3's own template emits. Swapping in _content_str would make the renderer diverge from apply_chat_template, not restore parity.

The Llama-3 comparison actually runs the other way. Same messages, unsloth/Llama-3.2-1B-Instruct:

TEMPLATE : ...assistant<|end_header_id|>\n\n[{'type': 'text', 'text': 'The answer is 4.'}]<|eot_id|>
RENDERER : ...assistant<|end_header_id|>\n\nThe answer is 4.<|eot_id|>
IDENTICAL: False

That template takes the message.content is mapping or message.content is iterable branch and stringifies the list, so Llama3Renderer._content_str is already a deliberate deviation — it's the exception in the package, not qwen3.py. For completeness, Qwen35Renderer._render_content handles list parts precisely because the Qwen3.5 template has a render_content macro that does. The consistent rule across renderers is "mirror your own template", with Llama-3 the one exception.

So this reads as a contract question rather than a bug:

1. Keep strict parity. Leave qwen3.py as is and treat the dropped text as upstream Qwen3 behaviour. If silent loss is the real complaint, qwen3.py could raise on non-string content instead of silently emptying it, so callers find out at render time.
2. Normalize content parts everywhere. Deliberately deviate for every renderer whose template can't handle parts, documented the way qwen35.py documents its existing deviation, with the parity tests updated to expect it.

Happy to implement either — (2) as a shared helper in base.py used by both qwen3.py and llama_3.py so the behaviour has one definition, plus tests. Which contract do you want?

Checked against renderers @ 1a5bd3b, transformers 5.15.0.

[vsimkus]

Thanks for checking with the template!

Users expect consistency, so OpenAI-style content parts should work the same across models. Most importantly, it shouldn't fail silently.

I'll leave the exact fix decision to the maintainers, but throwing an error would be a good start. Ideally, standardizing how all models process parts (option 2) feels like the best long-term solution.