chore: bump renderers to 0.1.8.dev1 and migrate to ParsedToolCall API#1366
chore: bump renderers to 0.1.8.dev1 and migrate to ParsedToolCall API#1366hallerite wants to merge 2 commits into
Conversation
The renderers 0.1.8.dev1 preview changes ``ParsedResponse.tool_calls`` from ``list[dict] | None`` to ``list[ParsedToolCall]`` (renderers PR #22) and forwards the ``tools=`` list into ``parse_response`` so XML-style parsers can apply schema-aware argument coercion (PR #28). It also adds a ``LagunaXS2Renderer``, drops ``torch`` from the renderer surface in favor of numpy, and fixes Qwen3.5 tool-response image emission. This PR updates ``RendererClient.from_native_response`` to read the new dataclass attributes (``tc.name`` / ``tc.arguments`` / ``tc.id`` / ``tc.status``) instead of indexing the old ``tc["function"]["name"]`` shape, and filters out non-OK parse attempts (``INVALID_JSON``, ``UNCLOSED_BLOCK``, …) so malformed blocks don't reach the tool loop. The renderer's native tool-call id is preferred when present (Kimi K2), falling back to the synthesized ``call_<index>`` over the OK subset. Regression tests pin both paths: dataclass round-trip with a native id and a mixed-status list where only the well-formed call is surfaced. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Existing tests already exercise the rollout paths end-to-end; the new shape doesn't need its own pinning test layer. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 4a27d0b. Configure here.
| has_content = bool(response.get("content")) | ||
| # ``tool_calls`` is now ``list[ParsedToolCall]`` (renderers >=0.1.8.dev1) | ||
| # — a non-empty list with only malformed attempts still counts as the | ||
| # model having tried to call a tool, so we don't filter by status here. |
There was a problem hiding this comment.
Validation bypassed for effectively empty malformed-only responses
Medium Severity
raise_from_native_response uses unfiltered tool_calls to decide the response is non-empty (has_tool_calls = bool(response.get("tool_calls"))), but from_native_response then filters to only ToolCallParseStatus.OK entries. When a model emits only malformed tool calls with no content or reasoning_content, the validation gate passes, yet the resulting Response has content="" and tool_calls=None — an effectively empty response that escapes the EmptyModelResponseError check designed to catch exactly this situation.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 4a27d0b. Configure here.
1 participant
Summary
renderersfrom0.1.8.dev0→0.1.8.dev1.RendererClient.from_native_responseto the newParsedToolCalldataclass shape —parsed.tool_callsis nowlist[ParsedToolCall](with.name/.arguments/.status/.id) instead oflist[dict].INVALID_JSON,UNCLOSED_BLOCK,MISSING_NAME,MALFORMED_STRUCTURE) so malformed tool blocks never reach the tool loop; prefers each call's native id when the format carries one (Kimi K2), falling back tocall_<i>over the OK subset.What changed upstream in
renderersbetween0.1.8.dev0and0.1.8.dev1:feat(parsing): per-attempt ParsedToolCall with status + token spans— the breaking change driving this PR.fix(parsing): schema-aware tool-arg coercion for XML-style parsers—parse_response(token_ids, *, tools=...);renderers.client.generatealready forwards the tools list, so verifiers picks this up transparently.feat: renderer emits numpy, not torch—multi_modal_datapayloads now ship numpy arrays. The vLLM-side mm encoder converts at itstorch.catboundary; verifiers treatsmulti_modal_dataas an opaque sidecar.LagunaXS2Renderer; fix(qwen35): emit images inline in tool-response content renderers#25 Qwen3.5 inline-image fix for tool responses; examples: add online SGLang HTTP recipe renderers#23 SGLang HTTP recipe; chore: license under Apache 2.0 renderers#27 Apache 2.0 license; build: derive version from git tags via hatch-vcs renderers#20 hatch-vcs versioning.Compare on the renderers repo:
renderers-v0.1.8.dev0...renderers-v0.1.8.dev1.Test plan
uv run pytest tests/test_renderer_client.py— 34 passed against renderers 0.1.8.dev1tests/minustests/test_envs.pywhich needsOPENAI_API_KEY) — green