Validation error on the 2nd turn of chat completions (Pydantic missing 'name' in AssistantMessage)

[handsomelcx]

Environment & Setup
llama-cpp-python Branch: JamePeng/llama-cpp-python (latest commits)
Server OS: Ubuntu 22.04 LTS (Intel Xeon CPU, NVIDIA V100 32G GPU)
Client OS: Windows 11 (running Cherry Studio / OpenWebUI)
Model: Qwen3.5-35B-A3B-Uncensored-HauhauCS-Aggressive-Q4_K_M.gguf
API Mode: OpenAI Compatible Server
Description
I can successfully complete the first turn of a conversation, but every second turn fails with a validation error [1, 2].
The issue is reproducible with multiple standard clients (Cherry Studio and OpenWebUI) [1, 2], which makes me suspect the problem is on the server side (related to message schema validation) rather than the client side.
Steps to Reproduce

1. First request
   code
   JSON
   {
   "model": "qwen3",
   "messages": [
   {
   "role": "user",
   "content": "你好"
   }
   ]
   }
   This works correctly and returns an assistant response (including a reasoning block).
2. Second request
   When the client packages the history and sends the second turn:
   code
   JSON
   {
   "model": "qwen3",
   "messages": [
   {
   "role": "user",
   "content": "你好"
   },
   {
   "role": "assistant",
   "content": ""
   },
   {
   "role": "user",
   "content": "你会什么本领"
   }
   ]
   }
   The server returns HTTP 500.
   Error Log
   The server console throws 8 validation errors, eventually complaining that name is a required field:
   code
   Text
   ('body', 'messages', 1, 'ChatCompletionRequestAssistantMessage', 'name')
   Field required
   The full error also contains:
   code
   Text
   Input should be 'developer'
   Input should be 'system'
   Input should be 'user'
   Input should be 'tool'
   Input should be 'function'
   Additional Observations & Brainstorming
   The assistant response contains thinking blocks similar to:
   code
   Text
   Thinking Process:
   ...

Final answer...
I did some brainstorming on this traceback and noticed a couple of interesting clues:
Potential Pydantic v2 Strictness:
In llama_types.py, if ChatCompletionRequestAssistantMessage is defined with name: Optional[str], Pydantic v2 will treat "name" as a strictly required key in the incoming JSON, even if its value can be None. Standard clients (Open WebUI/Cherry Studio) completely omit the "name" key when forwarding assistant history [1, 2], triggering the missing field validation error.
Possible Fix: Wrapping it as name: NotRequired[Optional[str]] might allow clients to omit it safely.
Reasoning Suffix Issue:
In the client's sent payload, I also noticed a weird trailing .cw inside the thinking block right before the closing tag:
Okay, ready to output.cw\n
I wonder if the server's reasoning parser is slightly modifying the assistant message, or if a routing logic mismatch is forcing Pydantic to validate the message against a different schema that strictly expects tool/name fields.
Expected Behavior
Standard assistant history messages without a name key:
code
JSON
{
"role": "assistant",
"content": "..."
}
should be accepted normally during multi-turn chats.
Questions for the Maintainer/Community
Is name intentionally required for assistant messages in recent versions?
Is this related to reasoning/thinking mode support, or is it a general schema definition oversight in llama_types.py?
Has anyone else seen similar validation issues during multi-turn chats with Qwen3 or other reasoning models?
I would be happy to provide additional logs or test specific commits if needed. Thanks!

[false200]

@handsomelcx

Your diagnosis is right. This is a server-side schema validation issue, not something related to Cherry Studio, OpenWebUI, or Qwen3 reasoning mode. The failure happens before inference even starts.

What’s happening is that turn 1 works because the request only contains a user message. Turn 2 fails because Pydantic tries to validate the assistant message in the chat history against ChatCompletionRequestAssistantMessage, and it rejects it during validation.

In the current fork, llama_cpp/llama_types.py defines the assistant message like this:

class ChatCompletionRequestAssistantMessage(TypedDict):
    role: Literal["assistant"]
    name: Optional[str]
    content: NotRequired[Optional[str]]

The issue is subtle but important. Optional[str] only means the value can be null, but it does not mean the key can be omitted. In Pydantic v2 TypedDict validation, the presence of the key is still required unless it is explicitly marked as optional via NotRequired.

Most clients send assistant messages like this:

{"role": "assistant", "content": "..."}

There is no name field at all, which causes validation to fail with a “Field required” error for name.

The other validation errors like “Input should be 'developer', 'system', 'user'” are just Pydantic evaluating the union of possible message types and failing each branch. The real root cause is the missing name field in the assistant schema.

Upstream abetlen/llama-cpp-python does not require a name field for assistant messages. This issue was introduced when the fork aligned with a newer OpenAI-style schema but used Optional[str] instead of NotRequired[Optional[str]].

To answer your questions directly:

This is not intentional. The name field is not required in normal OpenAI-compatible chat messages. Only certain special message types use it.

This is also not related to reasoning mode or Qwen3. The error occurs during request validation in FastAPI/Pydantic before the model or chat template is even involved.

Yes, this would affect any multi-turn request that includes assistant history in this fork. Qwen3 just makes it more visible because you are testing multi-turn reasoning flows.

The fix is straightforward. In llama_cpp/llama_types.py, change:

name: Optional[str]

to:

name: NotRequired[Optional[str]]

Alternatively, remove name entirely from the assistant message schema unless it is actually used for routing in your implementation.

This is the same class of issue that was already fixed in upstream for other fields like content, where Optional was replaced with NotRequired to correctly reflect OpenAI’s API behavior.

Until this is patched, you have a few workarounds. You can modify the client to always include "name": null in assistant messages, which will bypass validation. Or you can patch the server and reinstall, which is the clean fix. A quick test to confirm the diagnosis is to resend the same request but add "name": null to the assistant message; it should pass validation immediately.

There is a separate minor observation about empty assistant content. If the assistant message contains "content": "", that is likely coming from the client not persisting or mapping the previous response correctly, especially if reasoning output is stored separately. Once the schema issue is fixed, this won’t cause a crash, but it may affect model continuity if the history is incomplete.

The .cw artifact you mentioned is almost certainly unrelated and likely comes from template or chat formatting noise rather than the validation layer.

A minimal patch would be:

class ChatCompletionRequestAssistantMessage(TypedDict):
    role: Literal["assistant"]
-   name: Optional[str]
+   name: NotRequired[Optional[str]]
    content: NotRequired[Optional[str]]

This is worth reporting upstream or opening a PR for, since the fix is small and consistent with how other fields in the schema were corrected.