chore(main): release 8.46.1

[pjb157]

🤖 I have created a release beep boop

8.46.1 (2026-05-07)

Bug Fixes

• pass through client-side tool_calls instead of dispatching them (#1049) (88ac176)

---

This PR was generated with Release Please. See documentation.

[cloudflare-workers-and-pages]

Deploying control-layer with    Cloudflare Pages

Latest commit:	eccc451
Status:	⚡️  Build in progress...

View logs

[pjb157]

🤖 Created releases:

• v8.46.1

🌻

[Copilot]

Pull request overview

Release PR for dwctl v8.46.1, aligning repository metadata (crate version, lockfiles, and changelog) with the bug-fix release generated by Release Please.

Changes:

• Bump dwctl crate version from 8.46.0 to 8.46.1.
• Update both workspace and crate Cargo.lock entries for the dwctl package version.
• Prepend the 8.46.1 release notes to CHANGELOG.md and update the Release Please manifest.

Reviewed changes

Copilot reviewed 3 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
dwctl/Cargo.toml	Bumps the dwctl crate version to 8.46.1.
dwctl/Cargo.lock	Updates the dwctl package entry to 8.46.1 in the crate lockfile.
Cargo.lock	Updates the dwctl package entry to 8.46.1 in the workspace lockfile.
CHANGELOG.md	Adds the 8.46.1 section describing the included bug fix.
.release-please-manifest.json	Updates Release Please manifest to 8.46.1.

[doubleword-code]

Summary

This is a release PR (chore) that bumps the version from 8.46.0 to 8.46.1, incorporating bug fix #1049 which addresses an issue where client-side tool calls in the /v1/responses API were incorrectly being dispatched server-side, resulting in "Tool not found" errors.

The fix is well-designed and thoroughly tested. It correctly distinguishes between server-registered tools (which should be auto-dispatched) and client-side tools (which should be passed through as function_call output items per the OpenAI Responses contract). Approve - this is a solid bug fix with appropriate test coverage.

Research notes

The fix touches the multi-step orchestration flow for OpenAI Responses API. Key files modified:

1. dwctl/src/responses/transition.rs: Core transition function decide_next_action now takes resolved_tool_names: &HashSet<String> parameter and checks if all tool_calls are server-registered before dispatching
2. dwctl/src/responses/store.rs: Added resolved_tool_names: HashSet<String> field to PendingResponseInput struct
3. dwctl/src/responses/middleware.rs: warm_path_setup populates resolved_tool_names from the resolved tool set's keys
4. Test files: Updated fixtures and added two new unit tests for the client-side tool passthrough scenario

The root cause was that the SQL in tool_injection.rs only returns server-registered tools (joined via api_keys → user_groups → deployment_groups → deployment_tool_sources → tool_sources), but the transition function was unconditionally dispatching all tool_calls without checking this registry.

Suggested next steps

No blocking issues found. The PR author noted one unchecked item in their test plan:

[ ] Manual verification: hit /ai/v1/responses with service_tier: flex and a client-side tools: [{name: "read_pages"}] body; confirm response contains output: [{"type":"function_call", ...}] instead of erroring

Consider completing this manual verification before merging to ensure end-to-end behavior matches unit test expectations.

General findings

Positive observations

1. Correct fix strategy: The whole-batch passthrough approach is correct. As the comment explains, partial dispatch would leave the model expecting results for tool_calls the loop never ran — a state the model can't reason about.

2. Comprehensive test coverage: Two new unit tests cover the exact failure scenarios:

   • model_call_with_unregistered_tool_completes_for_client_dispatch: Single unregistered tool
   • model_call_with_mixed_registered_and_unregistered_completes: Mixed batch confirms whole-batch passthrough

3. Clear documentation: Code comments explain the "why" clearly, particularly:

   • Why all tool_calls pass through together (line 299-303 in transition.rs)
   • How the OpenAI Responses contract expects client-side tools to be handled (line 289-298)

4. Minimal invasive change: The fix threads the resolved_tool_names through existing data structures without changing the overall architecture. This reduces regression risk.

Minor observations

1. Empty resolved_tool_names handling: When resolve_tools_for_request returns Ok(None), an empty ResolvedToolSet is created (middleware.rs:609-615). This means ALL tool_calls will be treated as client-side tools, which is the correct fallback behavior.

2. Test fixture updates: The test helper functions in test/multi_step_executor.rs and test/responses.rs correctly initialize resolved_tool_names: std::collections::HashSet::new() for existing tests, maintaining backward compatibility.

3. No migration required: This is a pure code fix - no database schema changes needed since the resolved_tool_names field is already present in PendingResponseInput (an in-memory side-channel struct, not a database table).

No security, correctness, or performance concerns identified.