GitHub user da-daken added a comment to the discussion: Parallel Tool Call 
Execution

Thank you for raising the Python-side concerns – I have to admit I overlooked 
this side previously.

**1. The Python side and the per-call durable identity**  
Currently, the `actionState` recovery mechanism on both Java and Python sides 
is the same: matching is done using `functionId`, `argsDigest`, and 
`currentCallIndex`. The proposal above does not change the `actionState` 
recovery mechanism – it stays consistent with the previous behavior, because we 
still reserve pending slots in the order returned by the LLM before parallel 
tool execution begins.
The reason I wanted to change `functionId = "tool-call-" + toolCallId` is that 
both Java and Python currently use a fixed `functionId`. This creates issues 
for tools that, given the same function and same arguments, can return 
different results at different times – e.g., querying the weather at a certain 
location. Using a unique `functionId` can avoid that. That said, this seems 
like a somewhat independent concern, so I can file a separate issue and we can 
discuss it there.

---

**2. Collect-all isn't symmetric across the two languages today, which the 
parallel design will inherit**  
Yes, I checked the Python code and confirmed that it currently lacks the 
per-tool try‑catch structure. I'll add that after our discussion here wraps up, 
so that the semantics on the Java and Python sides become consistent.

---

**3. Does durableExecuteAllAsync need to be public API in v1?**  
Agreed – I'm fine with keeping `tool-call.parallel` as a configuration knob 
rather than exposing a public API for now.

---

**4. One concrete note on the barrier sketch, since it feeds the 
pool-exhaustion question**  
In the earlier design, the intention was to use the global thread pool, but I 
now agree that we should introduce a separate thread pool for parallel 
execution logic, with configurable parameters for users to tune.

---

Thanks again for the thoughtful review , Happy to discuss further if you have 
additional comments.

GitHub link: 
https://github.com/apache/flink-agents/discussions/855#discussioncomment-17495444

----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]

Reply via email to