Add workaround for templates requiring non-null content

[pwilkin]

As in topic, even though OpenAI standard is null content when assistant message contains tool calls, some templates explicitly require it to be non-null or they'll fail with an error.

[aldehir]

This was a problem with a few templates, #18485 defaults to the empty string when null. I'm guessing the problem is during capability evaluation? If so, we should just pass in "content": "" to every message, instead of a whole workaround. Seems unnecessary, IMO.

[pwilkin]

This was a problem with a few templates, #18485 defaults to the empty string when null. I'm guessing the problem is during capability evaluation? If so, we should just pass in "content": "" to every message, instead of a whole workaround. Seems unnecessary, IMO.

If I remember correctly, other templates on the other hand DO expect content to be null on tool_call messages because that's the OpenAI spec, so I would settle for a workaround.

[pwilkin]

Although if I'm wrong, then yeah, scrapping the capability check and just keeping the workaround would be fine IMO.

[aldehir]

It's already happening, and no one has complained so far 😊

[pwilkin]

Aight, will keep just the workaround.

[CISC]

Suggested change

	test_template(t, "null is undefined",
	"{% if null is not defined %}yes{% else %}no{% endif %}",
	json::object(),
	"yes"
	);
	}
	}

What are you trying to test here, we already have this test (null is a JSON thing), you can change y to null if you want:

llama.cpp/tests/test-jinja.cpp

Lines 189 to 193 in 20db3d4

	test_template(t, "is not defined",
	"{% if y is not defined %}yes{% else %}no{% endif %}",
	json::object(),
	"yes"
	);

[pwilkin]

Yeah, I wanted to do the explicit "null constant is alias for undefined" check.

[ngxson]

probably useful to leave a comment header explaining why the ID must be at a certain length (IIRC there was one or two templates enforces this?)

just in case we may come up with a better way in the future, we can come back and test the problematic template

[pwilkin]

Right, I'll add.

[ngxson]

I'm not 100% sure if this is expected by all templates. in theory, there can be regression in these cases:

• template check: if content is not none: (do something) else (do other things)
• template that wraps content inside special tokens, example: <message><tool>...</tool><content></content></message> --> in such case, content maybe expected to be none

but that's just in theory, for now I can't think of a way to verify it.

[pwilkin]

I thought the same, but @aldehir talked me out of it 😀 can always add the cap code if we change our mind.

[aldehir]

Trying to recall, but I believe this is where simply checking "non-null" is insufficient:

llama.cpp/models/templates/Qwen-Qwen3-0.6B.jinja

Lines 40 to 42 in bb02f74

	{%- if loop.last or (not loop.last and reasoning_content) %}
	{{- '<|im_start|>' + message.role + '\n<think>\n' + reasoning_content.strip('\n') + '\n</think>\n\n' + content.lstrip('\n') }}
	{%- else %}

This branch is only explored with a tool call + reasoning content. The Qwen3 template was not triggering the requires non-null check in Minja, so we were passing null content and it was throwing an exception. I think most templates are defensive against empty content, more than null content. A default of an empty string seems more reasonable to me. We are already passing in an empty string as of #18485. The capability checks do not align with this.