GitHub user weiqingy added a comment to the discussion: Parallel Tool Call Execution
Thanks! Overall this looks like the right direction to me. `reserve-N -> execute -> finalize-in-order`, with the cursor advancing only after the whole batch, seems to give a clean partial-recovery story: if we crash mid-fan-in, recovery can re-scan from `base`, reuse finalized slots, and handle the remaining `PENDING` slots. A few details that may be worth spelling out: - Python parity. The Java sketch is clear, but Python still needs the equivalent flow. Today `__await__` fuses execute + record, and `_record_call_completion` has no absolute index. So Python likely needs the same index-addressable primitives plus a submit-all -> yield-until-all -> record-in-tool-call-order path. - Timeout fan-in. When the batch timeout fires, should each unfinished slot be finalized as a timeout failure via `finalizeCallAt(..., TimeoutException)` so collect-all can proceed? Also, `cancel(true)` bounds the wait, but a blocking tool that ignores interruption may keep occupying the pool thread, so it may still be useful to document that distinction. - Return type. The internal `Outcome<T>` shape seems important. If the method returns only `List<T>`, a thrown tool can become indistinguishable from a null result unless the caller reads the slot state back. Returning per-call outcome objects would line up better with `ToolCallAction`’s success/error/responses maps. With those details clarified, the recovery model looks good to me. GitHub link: https://github.com/apache/flink-agents/discussions/855#discussioncomment-17576217 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
