#1894·Qwen3

Qwen3.8 chat template crashes on OpenAI JSON-string tool arguments

Author: Thump604Created Aug 14, 2026Updated Aug 14, 2026

Model and revision

  • Qwen/Qwen3.8-27B
  • revision 1d4bf0f2ff6012fd82039f2fa52739d0dd7c60c0
  • shipped chat_template.jinja

Problem

The template iterates tool_call.arguments|items. That works when arguments is already a mapping, but OpenAI-compatible assistant history normally carries function.arguments as a serialized JSON string.

Passing such history back through tokenizer.apply_chat_template raises instead of rendering the conversation:

python
messages = [
    {"role": "user", "content": "Look up Paris"},
    {
        "role": "assistant",
        "content": "",
        "tool_calls": [{
            "type": "function",
            "function": {
                "name": "lookup",
                "arguments": "{\"city\": \"Paris\"}",
            },
        }],
    },
]

tokenizer.apply_chat_template(messages, tokenize=False)

Observed failure:

TypeError: Can only get item pairs from a mapping.

Why this needs an authoritative Qwen decision

Qwen3.8's shipped template reconstructs historical calls using its XML <function> / <parameter> protocol. Simply inserting the JSON string verbatim avoids the Jinja exception but does not reconstruct that protocol and can stop downstream tool-call execution. Jinja/Transformers also does not provide a standard JSON-deserialization filter to safely recover the mapping inside this template.

Could Qwen clarify and implement the intended boundary?

  1. normalize OpenAI JSON-string arguments to mappings before template rendering, or
  2. define a model-native template representation for serialized arguments.

The same model revision also emitted empty historical thinking wrappers; the narrow independent fix for that issue is submitted as Qwen/Qwen3.8-27B discussion #48.

This report intentionally does not propose the broader community replacement template because it changes additional prompt and tool-protocol semantics.

Runtime mitigation status (2026-08-14)

Our vllm-mlx Runtime now mitigates this at the server boundary by normalizing OpenAI JSON-string tool arguments into mappings before invoking the Qwen chat template. That avoids the exception for requests passing through that server without changing Qwen3.8's XML tool-history protocol.

This does not resolve the upstream model-template behavior: the minimal tokenizer.apply_chat_template(...) reproduction above still fails on the official model revision, and direct Transformers users or other serving stacks remain affected. The issue therefore remains open for an authoritative Qwen contract or model-repository fix.