Simplify parallel#4829
Conversation
|
@codex give a thorough review, focus on lifetimes of tools call invocations |
|
Codex Review: Didn't find any major issues. 🚀 ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting |
jif-oai
left a comment
jif-oai
left a comment
There was a problem hiding this comment.
Much cleaner with the handled moved in the async block
- Replace manual pending call tracking with FuturesOrdered for response processing - Use RwLock and abort-on-drop for tool parallelization, supporting parallel and serial modes - Switch tokio-util dependency to use "rt" feature - Cleanup error handling and streamline handling of tool and non-tool response items
pakrym-oai
force-pushed
the
pakrym/simplify-parallel
branch
from
258b068 to
cbf6ced
Compare
jif-oai
left a comment
jif-oai
left a comment
There was a problem hiding this comment.
Ok once the comments are fixed
| tracker: SharedTurnDiffTracker, | ||
| sub_id: String, | ||
| pending_calls: Vec<PendingToolCall>, | ||
| lock: Arc<RwLock<bool>>, |
There was a problem hiding this comment.
lock is very generic (and even a reserved key word in some languages)
- this looks a bit like a hack. You do not even need the
bool. At least, have an empty lock
| match handle.await { | ||
| Ok(Ok(response)) => Ok(response), | ||
| Ok(Err(FunctionCallError::Fatal(message))) => Err(CodexErr::Fatal(message)), | ||
| Ok(Err(other)) => Err(CodexErr::Fatal(other.to_string())), |
There was a problem hiding this comment.
This will change a bit how the errors bubble. It means that in the serial path, if there is an error, we don't bubble it directly
Find by me but this changes the behaviour so we need to make sure it does not cause any issues
2 participants
make tool processing return a future and then collect futures.
handle cleanup on Drop