fix(chat_templates): bind loop_messages when default_system_message is None

[chuenchen309]

Problem

construct_chat_template(default_system_message = None) produces a template that raises as soon as the caller passes a system message:

Only user and assistant roles are supported!

The same template built with a default_system_message handles that input fine, so the failure depends on a parameter that is only meant to supply a fallback.

Cause

The system part binds loop_messages only inside the {% if %} arm (chat_templates.py:2640):

partial_system = \
    "{% if messages[0]['role'] == 'system' %}"\
        "{{ " + partial_system + " }}"\
        "{% set loop_messages = messages[1:] %}"
if default_system_message is not None:
    ...
    partial_system += "{% else %}"\
        "{{ '" + full_system + "' }}"\
        "{% set loop_messages = messages %}"\
    "{% endif %}"
else:
    partial_system += "{% endif %}"          # no else arm

Then, 8 lines below:

# Fix missing loop_messages
if "{% set loop_messages = messages %}" not in jinja_template:
    jinja_template = jinja_template.replace(
        "{% for message in loop_messages %}",
        "{% for message in messages %}",
        1,
    )

That step exists for templates with no {SYSTEM} part, which never bind loop_messages at all. But it tests for the unconditional binding. In the None path loop_messages is bound — at :2640, to messages[1:] — just not unconditionally. So the test passes, the loop is rewritten to messages, and the messages[1:] skip is undone. The system message reaches the loop and hits raise_exception.

loop_messages isn't missing here; only the {% else %} arm is.

Fix

Add the {% else %} arm, mirroring the is not None branch minus the default text. loop_messages is then always bound, and the rewrite no longer fires because the unconditional binding is present.

How I tested this

Rendered the generated template for all four combinations, same chat_template, same inputs:

default_system_message	input	before	after
None	system message	raise_exception	'Be terse.\n### User: Hi\n'
None	no system message	'### User: Hi\n'	unchanged
'You are helpful.'	system message	'Be terse.\n### User: Hi\n'	unchanged
'You are helpful.'	no system message	'You are helpful.\n### User: Hi\n'	unchanged

Only the broken row changes, and it lands on the same output the is not None row already produced — which is right, since a caller-supplied system message makes the default irrelevant.

Checked separately that the Fix missing loop_messages step still fires for a template with no {SYSTEM} part, i.e. its actual purpose: identical render before and after.

Tests added to tests/python/test_construct_chat_template_validation.py, which already had the CPU-only fake tokenizer. Red before the fix (only the [None] parametrization; the ['You are helpful.'] one passes either way), green after. tests/python/: 305 → 308 passed, identical single pre-existing failure (test_negative_control_no_tokenizers), --ignore on test_unsloth_run_tool_policy_resolver.py which needs pydantic (not installed here, unrelated to this change). ruff check clean; scripts/run_ruff_format.py applied to the test file — chat_templates.py is in the hook's exclude list, so it is left formatted as-is.

Notes

I found this by rendering the produced Jinja rather than reading the builder — my first two readings of the mechanism were both wrong, and only the actual template output showed that the loop had been rewritten.

---

Disclosure: this contribution is fully AI-authored and autonomous (Claude Code, acting on this account). An AI found the bug, ran the repro, wrote the tests, and wrote this description; the human account holder reviews every change and is accountable for it. The verification above is real and re-runnable from the diff — it was just done by an AI, not a person. If unsupervised AI contributions aren't what you want here, say the word and I'll close this.

[gemini-code-assist]

Code Review

This pull request fixes an issue in the chat template generation where loop_messages was not being bound when default_system_message was set to None. It updates the Jinja template generation logic in unsloth/chat_templates.py to include an {% else %} block that binds loop_messages = messages, and adds corresponding unit tests to validate this behavior. No review comments were provided, so there is no feedback to address.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[danielhanchen]

Thanks for the fix. I reproduced the bug and confirmed the fix through the real apply_chat_template path: on main a {SYSTEM} template with default_system_message=None and a caller system message raises TemplateError: Only user and assistant roles are supported! (checked with Qwen2.5-0.5B and TinyLlama), and with your change it renders correctly with a single BOS. The Ollama modelfile is byte identical, and a late or second system message still correctly raises.

I pushed one adjustment on top (11c7af3):

1. Scoped the new else arm to templates that actually contain {SYSTEM}. The unconditional binding was also firing for a template with a static prefix but no {SYSTEM} placeholder, where system_part is still non-empty. In that case a caller system message was silently dropped instead of raising, which diverged from the default_system_message set path (which still raises). Guarding on "{SYSTEM}" in system_part keeps your fix for the intended case and preserves the raise for prefixes that cannot represent a system message.

2. Strengthened the tests: assert the default does not leak when a caller system message is present, and added a regression test for the static prefix case.

After this, the only behavior difference versus main is the intended {SYSTEM} plus None fix. tests/python/test_construct_chat_template_validation.py passes (12 tests) and ruff is clean.

[danielhanchen]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. 👍

Reviewed commit: 11c7af355c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[danielhanchen]

Thanks!