Skip to content

Draft: parse tool_calls arguments #4921

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
la1ty wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Draft: parse tool_calls arguments #4921

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
43cd9bf
Draft: parsing tool_calls arguments
la1ty May 18, 2026
871b4a4
Apply suggestion from @gemini-code-assist[bot]
la1ty May 18, 2026
b0a77f3
fix linting
la1ty May 18, 2026
5743c10
Merge branch 'xorbitsai:main' into draft-parse-arguments
la1ty May 19, 2026
9cc4e0f
fix test
la1ty May 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 10 additions & 1 deletion xinference/model/llm/tests/test_utils.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -79,7 +79,16 @@ def test_transform_messages_preserves_tool_call_fields():
assert transformed[1] == {
"role": "assistant",
"content": None,
"tool_calls": messages[1]["tool_calls"],
"tool_calls": [
{
"id": "call_bed4c5f1",
"function": {
"arguments": {"file_path": "README*"},
"name": "view_file_in_detail",
},
"type": "function",
}
],
}
assert transformed[2] == {
"role": "tool",
Expand Down
20 changes: 20 additions & 0 deletions xinference/model/llm/utils.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -811,6 +811,26 @@ def _transform_messages(
)
new_message = dict(msg)
new_message["content"] = new_content if new_content else None
# Parse JSON-encoded arguments in tool_calls to dicts,
# so Jinja2 templates can iterate them with |items.
if new_message.get("tool_calls"):
tool_calls = []
for tc in new_message["tool_calls"]:
tc = dict(tc)
func = tc.get("function")
if isinstance(func, dict) and isinstance(
func.get("arguments"), str
):
func = dict(func)
try:
parsed_args = json.loads(func["arguments"])
if isinstance(parsed_args, dict):
func["arguments"] = parsed_args
except (json.JSONDecodeError, TypeError):
pass
tc["function"] = func
Comment thread
la1ty marked this conversation as resolved.
tool_calls.append(tc)
new_message["tool_calls"] = tool_calls
Comment on lines +814 to +833

@gemini-code-assist gemini-code-assist Bot May 18, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

This change introduces a breaking change for models whose chat templates expect tool_calls arguments to be a JSON string. As noted in the PR description, templates using string concatenation or assuming a string type will fail. Instead of a global conversion in _transform_messages, a safer approach would be to add a fromjson filter to the Jinja2 environment in _compile_jinja_template. This allows templates that need structured data to opt-in without breaking others. If this global change is desired, it should likely be made conditional based on the model family or template requirements.

@qinxuye qinxuye May 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This global conversion is too broad for _transform_messages. That helper feeds vLLM, MLX, SGLang, and several multimodal paths, while the OpenAI-compatible message shape and existing tests expect tool_calls[].function.arguments to remain a JSON string. Converting it to a dict here changes the message contract for every template, including templates that concatenate or tojson the argument string. Please keep _transform_messages preserving the input shape and make the JSON parsing opt-in in the template path, for example via a Jinja fromjson filter or a model/template-specific branch.

@la1ty la1ty May 30, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I know this. Actually in the initial version in #4914, I implemented a from_json filter. However, this way requires modifying templates of many existing models (including future models?).

At the moment, I don't have a good solution. By comparison, directly parsing it seems a bit simpler.

@qinxuye qinxuye May 30, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A safer way to keep this scoped is:

  1. Keep _transform_messages preserving the OpenAI-compatible message shape, so tool_calls[].function.arguments stays a JSON string.
  2. Add an opt-in filter in _compile_jinja_template, e.g. jinja_env.filters["fromjson"] = lambda s: json.loads(s) if isinstance(s, str) else s with defensive fallback.
  3. Update only the templates that need structured arguments to use something like {% set args = tool_call.arguments | fromjson %} before iterating args.items().
  4. Keep the existing preservation test, and add a focused template-rendering test showing that a template using fromjson can iterate JSON string arguments.

This avoids changing every backend/template caller at once while still supporting templates that require dict-style argument access.

transformed_messages.append(new_message)

return transformed_messages
Expand Down
Loading