Skip to content

fix: spawn GetToolDefs to avoid blocking actor loop#1579

Closed
joaquinhuigomez wants to merge 1 commit into0xPlaygrounds:mainfrom
joaquinhuigomez:fix/tool-server-actor-blocking
Closed

fix: spawn GetToolDefs to avoid blocking actor loop#1579
joaquinhuigomez wants to merge 1 commit into0xPlaygrounds:mainfrom
joaquinhuigomez:fix/tool-server-actor-blocking

Conversation

@joaquinhuigomez
Copy link
Copy Markdown
Contributor

Fixes #1573 (Issue 2)

GetToolDefs with a prompt awaits vector store I/O inline in the actor loop, blocking all concurrent messages (CallTool, AddTool, etc.) for the duration of the round-trip. CallTool already avoids this by spawning to a separate task.

Changes

  • Wrap dynamic_tools in Arc so it can be shared with spawned tasks
  • Spawn GetToolDefs handler to a separate task, matching the existing CallTool pattern
  • Extract get_tool_definitions into a free function that takes owned/shared references instead of &mut self
  • Handle ToolError response variant in ToolServerHandle::get_tool_defs

Test plan

  • All 4 existing tool::server tests pass (including test_toolserver_dynamic_tools)
  • No API surface changes — dynamic_tools field is private, Arc wrapping is internal

Wrap dynamic_tools in Arc and spawn GetToolDefs handler to a separate
task, matching the existing CallTool pattern. This prevents vector store
I/O from blocking the actor loop and starving concurrent messages.
@gold-silver-copper
Copy link
Copy Markdown
Contributor

@joaquinhuigomez Hey there, please run cargo fmt to make all checks pass, thank you 🙏

@gold-silver-copper
Copy link
Copy Markdown
Contributor

Replaced by #1607

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: ToolServer actor loop blocks under concurrent tool execution and dynamic tool lookups

2 participants