No User Query Found in Messages: Qwen Tool Loop Fix

This is lines 88 to 101 of the Qwen3.8-27B chat_template.jinja, verbatim. The same block sits at lines 67 to 80 of the Qwen3.5-27B and Qwen3.6-27B templates, and the same raise appears in the Qwen3.5-35B-A3B and Qwen3.6-35B-A3B templates.

{%- set ns = namespace(multi_step_tool=true, last_query_index=messages|length - 1) %}
{%- for message in messages[::-1] %}
    {%- set index = (messages|length - 1) - loop.index0 %}
    {%- if ns.multi_step_tool and message.role == "user" %}
        {%- set content = render_content(message.content, false)|trim %}
        {%- if not(content.startswith('<tool_response>') and content.endswith('</tool_response>')) %}
            {%- set ns.multi_step_tool = false %}
            {%- set ns.last_query_index = index %}
        {%- endif %}
    {%- endif %}
{%- endfor %}
{%- if ns.multi_step_tool %}
    {{- raise_exception('No user query found in messages.') }}
{%- endif %}

Three consequences follow from the text, and each one rules a suspect in or out.

Tool messages never count. The template later renders role: tool messages inside a user turn as <tool_response>...</tool_response>, but the check only inspects message.role == "user". A conversation of one system message and fifty tool results has zero queries.

Tool output sent as a user message does not count either. Some clients send tool results as role: user with the text already wrapped in <tool_response> tags. The startswith and endswith test exists to reject exactly that.

Array content is not the cause. The render_content macro, lines 3 to 40 of the same file, iterates a list and emits each text item as plain text before the test runs. An OpenAI-style [{"type": "text", "text": "..."}] user message counts as a query. A hypothesis in OpenCode issue 25168 blamed array content after compaction; the 3.5+ template text contradicts it.

The error is new with Qwen 3.5. The Qwen3-8B template runs the same backwards loop but has no raise_exception after it, and the Qwen3-235B-A22B-Instruct-2507 and Qwen3-Coder-Next templates have no query check at all, so a query-less transcript rendered silently. A harness that worked against Qwen3 can start failing on the upgrade to 3.5 without changing a line.

The same check produces different strings and status codes, because each engine either runs the Jinja template or reimplements it. Paste your error, match the row.

Ollama's version is lowercase with no trailing period, because it comes from validateMessages in model/renderers/qwen35.go, a Go port of the check. That function opens with if r.variant != qwen35Renderer38 { return nil }: it runs only for the qwen3.8 renderer. The registry config for qwen3.8:27b selects renderer qwen3.8, while qwen3.6:27b selects renderer qwen3.5. That is why a community reproduction on issue 17778 got a 500 on qwen3.8:27b and a 200 on qwen3.6:27b with an identical body, even though the Hugging Face template for Qwen3.6 does raise.

The llama.cpp column number is exact. Line 100 of the 3.8 template is four spaces, then {{- , then raise_exception, which puts the opening parenthesis at column 24.

One symptom does not look like an error at all. OpenCode issue 47273, open since September 4, describes an OpenCode agent on Ollama qwen3.8:27b that stalls after several successful tool calls: the client retries silently with exponential backoff and the GPU idles. Sending another user message wakes it temporarily, which fits this check, since that message gives the template a query again.

Capture the failing request body first. On a bench box running Ollama, the server can write it out for you:

OLLAMA_DEBUG_LOG_REQUESTS=1 ollama serve
# the failure itself is logged at ERROR on a stock server:
# level=ERROR msg="chat prompt error" error="no user query found in messages"

OLLAMA_DEBUG_LOG_REQUESTS writes request bodies and replay curl commands to a temporary directory. Do not turn it on for hosts that hold regulated data; capture from a bench replay instead.

Then count what the body actually contains. The second query mirrors the template's test: user role, content flattened to text, trimmed, not wrapped in <tool_response> tags.

# Roles in the body you actually sent
jq -c '[.messages[].role] | group_by(.) | map({(.[0]): length}) | add' body.json

# User turns the Qwen template will accept as a query (0 = this request will fail on any engine)
jq '[.messages[]
     | select(.role == "user")
     | (if (.content | type) == "string" then .content
        else ([.content[]? | .text? // ""] | join("")) end)
     | gsub("^\\s+|\\s+$"; "")
     | select((startswith("<tool_response>") and endswith("</tool_response>")) | not)
    ] | length' body.json

The reading is binary. A count of 0 means the client sent shape 2, 3 or 4, and no server setting will fix it. A count of 1 or more, with Ollama still returning the error, means shape 1: server-side pruning removed a user turn that was in the body. The jq approximation reads only text parts, so an image-only user turn becomes an empty string and still counts, just as it does in the template, which renders it as a vision placeholder.

To reproduce on Ollama without generating a token, set _debug_render_only. The debug branch in server/routes.go runs after chatPrompt, so a failing body returns the same 500 at zero cost. This minimal body mirrors the community reproduction:

curl -s -w '\nHTTP %{http_code}\n' http://localhost:11434/api/chat -d '{
  "model": "qwen3.8:27b",
  "stream": false,
  "_debug_render_only": true,
  "messages": [
    {"role": "system", "content": "You are a coding agent."},
    {"role": "assistant", "content": "", "tool_calls": [{"function": {"name": "read_file", "arguments": {"path": "README.md"}}}]},
    {"role": "tool", "tool_name": "read_file", "content": "# project"}
  ]
}'
# expected per the v0.34.3 source:
# {"error":"no user query found in messages"}
# HTTP 500
# Add {"role": "user", "content": "Summarise the README"} after the system message and it renders.

Swap the model to qwen3.6:27b and the same body renders, because that model uses the qwen3.5 renderer. For shape 1, replay your captured body the same way and compare its rendered size against the CONTEXT column of ollama ps, which the num_ctx post explains.

Every engine-level fix above moves the cliff, hides the symptom, or turns it into a different error. The fix that works on all four engines is two rules in the harness: the original user task never enters the compactable region, and no tool result enters history uncapped.

MAX_TOOL_CHARS = 8_000  # size to your window; the 17778 bisect passed at 2K per result

def add_tool_result(history, call_id, text):
    if len(text) > MAX_TOOL_CHARS:
        text = text[:MAX_TOOL_CHARS] + f"\n[truncated {len(text) - MAX_TOOL_CHARS} chars; ask for a range]"
    history.append({"role": "tool", "tool_call_id": call_id, "content": text})

def is_query(m):
    if m["role"] != "user":
        return False
    c = m.get("content") or ""
    if isinstance(c, list):  # the template flattens text parts before testing
        c = "".join(p.get("text", "") for p in c)
    c = c.strip()
    return not (c.startswith("<tool_response>") and c.endswith("</tool_response>"))

def build_request(system, task, history):
    # The original user task is never inside the compactable region.
    msgs = [{"role": "system", "content": system},
            {"role": "user", "content": task}] + history
    assert any(is_query(m) for m in msgs), "no plain user turn"
    return msgs

history holds the assistant tool calls and tool results; whatever compaction does to it, task is rebuilt into position 1 on every request. The assertion is the template's own test, run before the bytes leave your process, so the failure is a local exception with a stack trace instead of a remote 500 hidden behind a retry loop.

Capping tool results at write time is what keeps shape 1 from appearing in the first place: the bisect's body failed on 95,000 characters of tool output, not on the number of turns. Offloading large results to a file and passing a reference is the stronger version, covered with compaction triggers in when to compact and how to offload large tool results. When you drop old history, drop assistant tool calls and their tool results as pairs; the sibling transcript-shape error on the Anthropic API is what happens when you split them. And a summary that loses the task can restart work the agent already did, which is how summary loss restarts tool loops.

This is also where the on-prem answer differs. Ollama's pruning keeps the request alive by deciding for you which turns the model loses, and the only record of that decision is a DEBUG log line that a stock server does not emit. System messages survive by design; operator instructions and policy text sent as user or assistant turns do not. In a regulated deployment, where you may need to show which instructions governed an action, a silent server-side cut is worse than a crash. Use truncate: false on the native API or an engine that rejects oversize prompts, and let the client own the message list. On this point the pruning trade-off is a real difference in Ollama versus vLLM, not a detail.

Keep the captured body as a fixture and run it against the model name and window you actually deploy. The case-insensitive grep catches both the lowercase Ollama spelling and the capitalized Jinja one.

code=$(curl -s -o out.json -w '%{http_code}' http://localhost:11434/v1/chat/completions \
  -H 'Content-Type: application/json' -d @fixtures/failing-body.json)
if grep -qi 'no user query found in messages' out.json; then
  echo "regression: transcript lost its user turn (HTTP $code)"; exit 1
fi

Pair it with the jq count as a pre-send gate in the harness's own tests: every request the agent builds in a recorded long session must have a plain user count of at least 1. The replay catches the server side, the count catches the client side, and between them a Qwen upgrade or a context change cannot reintroduce the error unnoticed.

This week, take the last failing request from your agent logs, run the two jq commands on it, and write the plain user count next to the ticket. If it is 0, the fix is in your harness; if it is 1 or more, it is in your Ollama window. The rest of the local-serving decisions sit in our LLMs and models pillar.