GitHub user weiqingy added a comment to the discussion: Parallel Tool Call Execution
Thanks, that PENDING invariant makes sense. I agree `null/null` in the completion-only path can stay as “successful null result”, and the `Optional.of(null)` issue feels like a separate fix. For #855, maybe the useful next step is to make “reserve slots” a little more explicit in the design. If non-reconcilable calls never persist PENDING, then I think a parallel batch has two possible shapes: either record nothing until ordered fan-in, so failover before fan-in re-executes those calls, or introduce index-addressable batch state so slot i can be persisted/finalized independently without depending on completion order. Would it be good to spell out which shape we want? The current single-cursor APIs (`appendPendingCall`, `finalizeCurrentCall`, Python `_record_call_completion`) seem to express “next call” well, but not yet “N calls in flight, record slot i later”. Python may need the same concrete flow too: submit all -> wait/yield -> record in tool-call order, rather than record as each future completes. On `RunnerContext`, exposing the batch primitive sounds reasonable to me if the failure/recovery semantics are defined first and we mark it experimental/beta. One thing worth considering is whether a bare `List<T>` is too fail-fast-shaped for the tool-call use case; a per-call outcome type might line up better with collect-all. One final question: is timeout intentionally out of scope for v1? If so, it might be useful to document that tools are expected to bound their own I/O, since one never-returning tool could otherwise hold the fan-in open. GitHub link: https://github.com/apache/flink-agents/discussions/855#discussioncomment-17568666 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
