Pull requests / #2572

#2572 tool_call_recovery: a parameter written <parameter name="X"> or as one JSON <parameter> keeps its value (#2451)

open · @qiuzan2001 · 0 コメント · GitHub で見る

Server & APIModels & quantsSecurityDocumentationLinux

本文

Fixes the recoverable part of #2451 (forms 1-3 of the report), based on the patch and tests @mbaaku posted there
(credited as co-author). Form 4 (no value generated at all) and the `<arg_value>` form are left out.

**What it changes.** `parse_tool_call` reads only `<parameter=NAME>`. Coder IQ1_M with a coding agent's 21 tools
wrote `<parameter name="command">`, `<parameter name=command>` or a nameless `<parameter>` holding every argument as
JSON; those calls reached the client with empty arguments (19 of 35 broken `Bash` calls in one session on 0.1.44.1).
With `"tool_call_recovery": true` and tools declared, a small filter (`ParamForms`) in front of `OutputParser`
rewrites those forms into `<parameter=NAME>` (the JSON one into one parameter per key), so the streamed `tool_args`
and the final call agree. Changes from the posted patch, after two reviews:
- it rewrites only where a parameter opens (after the `<function=NAME>` tag or a `</parameter>`), never inside a
  value: a file that documents the call format (#210) keeps its text, and prose that mentions `<function=` is not
  touched;
- a `</function>` inside a value is the value's text, as `param_end` already treats it;
- a partly arrived `<parameter name=...` is held at most 512 characters; `finish()` keeps its name and flushes the
  filter first; the server logs `[strata] tool_call_recovery: N parameter tag(s) in another form read as
  <parameter=NAME> (#2451)`; one paragraph in docs/DETAILS.md ("Tool calls in other forms").

**What it leaves alone.** Everything without the switch (the filter is not created; `feed`/`finish` run as before),
and the template's own form with it (byte-identical through the filter in the reviewer's 20,000-case fuzz). One
ambiguity stays: inside a value, `</parameter>` followed by `<parameter name="y">` reads as the next parameter,
because that is exactly what a real call in this form looks like.

**How it was checked.**
- New `serve/test_param_forms.py` (13 tests): the report's raw samples in each form, streamed in 1/3/7-character
  pieces and whole, after and inside the thinking; the streamed `tool_args` equal the final arguments; the template
  form unchanged; a value that shows the forms (#210) and a value holding `</function>` (steps 1-7) kept; prose
  untouched; off without the switch; the rewrite count. On `main` most fail (no filter).
- With the venv's Python (it has `regex`): `serve.test_param_forms`, `test_tool_name_space`, `test_parser_track`,
  `test_reasoning_rescue`, `test_reasoning_tools`, `test_responses`, `test_server`: OK.
- Python 3.14, Ubuntu (Linux 7.0); no GPU, no Coder IQ1_M run here.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

関連リンク

インストール・モデル・リリースへの站内リンク。