GitHub user joeyutong added a comment to the discussion: Parallel Tool Call Execution
> So if a non-reconciler tool is still in flight at failover, a reserved > PENDING slot could recover as a successful null result instead of re-running On the `PENDING` slot point, I think the current invariant is that non-reconcilable calls do not write `PENDING` slots. They only record a terminal `CallResult` after completion, so recovery is not expected to see a `PENDING` slot for them; if no terminal record exists, re-execution is expected. With that contract, `resultPayload == null && exceptionPayload == null` in the completion-only path should mean a successful `null` result, not an unfinished call. The current `Optional.of(null)` path is indeed a bug because it will throw `NPE`, but that seems like a separate fix. > keeping durableExecuteAllAsync off public RunnerContext is still the right > direction, but the internal seam needs a name On the API boundary, I am leaning toward exposing the batch primitive on `RunnerContext`, as long as the failure and recovery semantics are clearly defined first. We could mark it as experimental/beta in the first version. GitHub link: https://github.com/apache/flink-agents/discussions/855#discussioncomment-17555236 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
