GitHub user joeyutong added a comment to the discussion: Parallel Tool Call Execution
Thanks for proposing this alternative. I agree that expressing each tool call as an independent event/action execution could reuse the existing action-level recovery model. However, I see a few structural gaps between the current event/action model and semantics equivalent to `executeAllAsync`: 1. **Representing generic child executions.** `AgentPlan` currently contains static event-to-action bindings. Pre-registering tool-specific child actions could solve the tool-call case, but a generic `executeAllAsync` accepts arbitrary runtime-created `DurableCallable`s. Turning those callables into child executions would still require a generic executable descriptor and registry, or some form of dynamic executable registration. 2. **Durable fan-in state.** The current durable state is scoped to an individual action/event. There is no shared durable join state that tracks the expected children, accumulates partial outcomes, deduplicates results, and determines when the batch is complete. 3. **Returning the result to the parent action.** Even if fan-in produces a final batch result, it cannot currently return that result to the original action invocation. An action's emitted events are routed only after the action finishes, so the parent cannot emit child events, remain suspended, and later resume at the original `executeAllAsync` call site. Once the fan-out action finishes, the result can only trigger a new action through another event. Filling these gaps seems like a substantial runtime change rather than a straightforward reuse of the current event/action model. If such a generic mechanism were introduced, I can see the benefits of reusing the existing action-level recovery model and making child executions first-class, scheduler-visible units. However, if each child action ultimately just wraps one `durableExecuteAsync` call, I am not yet seeing many additional concrete benefits over implementing `executeAllAsync` directly for parallel tool calls. Could you elaborate on the broader use cases or runtime benefits you expect from this model? GitHub link: https://github.com/apache/flink-agents/discussions/855#discussioncomment-17592750 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
