fix: reject tool_use blocks with empty id or function name

[EleanorWho]

The Anthropic translation silently substituted empty strings when upstream tool calls omitted their id or function name, producing schema-invalid tool_use blocks. Validate both fields are non-empty before constructing a block, returning a transformation error (finite) or FilterError (streaming) instead.

Summary

• Reject upstream tool calls with missing or empty id or function name instead of silently substituting empty strings, which produced schema-invalid Anthropic tool_use blocks
• Finite responses now return a transformation error; streaming responses return a FilterError
• Added unit tests for missing and empty id and name in both cases

Related issue

Closes #941

Validation

• New unit tests cover missing id, empty id, missing name, empty name
• Existing tool-call tests pass unchanged
• make test and make lint pass

[praxis-bot-app]

Unsigned commits: b657c66. Please sign your commits.

[praxis-bot]

PR Review

Validates that upstream tool-call id and function name are non-empty before constructing Anthropic tool_use blocks, returning errors instead of silently producing schema-invalid blocks.

Assessment

The finite-response validation and the extracted extract_tool_id_and_name helper are correct. Error types align with their respective call sites (String for transform_response, FilterError for the streaming path). The four new tests cover missing and empty variants for both fields in the finite path.

Severity	Count
Medium	1

Non-inline findings

None — all findings are inline.

[leseb]

[P2] Missing streaming IDs bypass validation — mod.rs:651
An omitted/non-string id skips emit_tool_block_start, returns Ok, and can emit an orphan input_json_delta. A diagnostic test reproduced this. Validate unopened calls before emitting arguments.

[P2] Nonempty but schema-invalid IDs remain accepted — response.rs:188, mod.rs:731
Issue #941 and the checked-in Anthropic schema require IDs matching ^[a-zA-Z0-9_-]+$. Both paths only reject empty strings, so values such as call.bad still produce invalid tool_use blocks.

[EleanorWho]

[P2] Missing streaming IDs bypass validation — mod.rs:651 An omitted/non-string id skips emit_tool_block_start, returns Ok, and can emit an orphan input_json_delta. A diagnostic test reproduced this. Validate unopened calls before emitting arguments.

[P2] Nonempty but schema-invalid IDs remain accepted — response.rs:188, mod.rs:731 Issue #941 and the checked-in Anthropic schema require IDs matching ^[a-zA-Z0-9_-]+$. Both paths only reject empty strings, so values such as call.bad still produce invalid tool_use blocks.

Thank you @leseb , these two are all addressed in the commit f567517. The coverage-check error is probably flaky. It's unrelated to my changes, and the coverage-check passes locally. Can you trigger a re-run to see?

[praxis-bot]

PR Re-Review

The new commit addresses the previous finding by adding streaming-path tests (INVALID_TOOL_CALL_CASES with five cases including invalid-format id). The is_valid_tool_use_id helper and the streaming condition simplification look correct.

Severity	Count
Medium	1

Non-inline findings

None — all findings are inline.

[leseb]

Remaining blockers:

• Add the missing finite invalid-format ID regression test.
• Add required synthetic fixture, manifest/generated README, and functional/client coverage for this transformation change.
• Rerun CI; current coverage failure is an unrelated AddrInUse flake.

[leseb]

@EleanorWho final:

[P2] The new fixture only tests stream: false (invalid-tool-id.yaml:22). The PR changes streaming rejection too, but that path lacks end-to-end and official Anthropic SDK coverage.

Thanks

[EleanorWho]

@EleanorWho final:

[P2] The new fixture only tests stream: false (invalid-tool-id.yaml:22). The PR changes streaming rejection too, but that path lacks end-to-end and official Anthropic SDK coverage.

Thanks

@leseb
The invalid tool ID is detected during response-body processing, after the upstream 200 status and SSE headers have already been sent to the client. The filter then returns a FilterError, and the proxy aborts the response stream.

A low-level client may therefore observe 200 text/event-stream headers with no body, but this is not a normally completed empty SSE response. The reqwest-based inference fixture runner instead reports a body read error (ReplayHttp) because the stream ended prematurely.

This means that adding a fixture expecting a completed “200 + empty SSE body” would require either changing the production filter behavior or teaching the fixture runner to model an aborted stream. Could you confirm which client-visible behavior the SDK coverage should assert?