fix: Fix parallel tool calling when tools interact with State#11690
Open
sjrl wants to merge 3 commits into
Open
fix: Fix parallel tool calling when tools interact with State#11690sjrl wants to merge 3 commits into
State#11690sjrl wants to merge 3 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Contributor
Coverage reportClick to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related Issues
Proposed Changes:
Fixed a bug in
Agent(and the underlying tool invocation) where parallel tool calls in a single step did not respect read/write dependencies onState. Tool arguments were prepared once, up front, from the initial state, so a tool reading aStatekey viainputs_from_statenever observed a write made by another tool in the same step viaoutputs_to_state. For example, two calls to a retrieval tool that both reads and writes thedocumentskey would each see the original documents instead of the second call seeing the first call's results.Tool calls within a step are now scheduled into batches based on their
inputs_from_stateandoutputs_to_statemappings. Calls that only read, or that touch disjoint keys, still run in parallel; a call that reads a key another call writes is run in a later batch, after that write has been merged intoState, with its arguments re-prepared so it sees the updated value. Tools that receive the liveStateobject are treated as reading and writing every key and run on their own. The order the LLM requested the calls in no longer affects correctness.How did you test it?
New tests and added regression tests exemplifying the previous incorrect behavior.
Notes for the reviewer
Checklist
fix:,feat:,build:,chore:,ci:,docs:,style:,refactor:,perf:,test:and added!in case the PR includes breaking changes.