GitHub user weiqingy added a comment to the discussion: Parallel Tool Call 
Execution

Thanks, that closes all three from my side. Pre-filling missing tools with a 
`FAILED` outcome so the indices stay strictly aligned is a good catch that 
nobody asked for.

**On `tool-call.parallel` defaulting to `true`.** I held this while the 
recovery model was still open, but it's probably the last moment to raise it, 
so one question. The migration note has existing multi-tool jobs getting 
parallel behavior automatically on JDK 21+, and the agreed mitigation for the 
higher duplicate-call risk on failover is documentation in the configuration 
guide for *enabling* parallel tool execution. With the default at `true`, 
though, would the users most exposed to duplicate calls be exactly the ones who 
never enable it and so never see that note? Would shipping v1 opt-in 
(`parallel=false`) and flipping the default once the model has soaked in real 
deployments be too conservative, or does the latency win feel worth having it 
on out of the box?

**One thing I want to check on the timeout round-trip.** If I'm reading the 
current code right, "rebuilt back into `TIMED_OUT` by exception type" may not 
hold on the Java side yet: `toException()` returns a bare `new 
RuntimeException(exceptionClass + ": " + message)` 
(`RunnerContextImpl.java:334-336`) and `CallResult.Status` is only `PENDING | 
SUCCEEDED | FAILED` (`CallResult.java:39-43`), so would `instanceof 
BatchTimeoutException` still match after recovery? The class *name* does 
survive on the wire (`:315`, `:331`) — would comparing that name directly in 
the batch read-back be enough, or were you picturing `TIMED_OUT` as a real 
persisted status? The second changes the stored format, so I wasn't sure which 
way you were leaning. And since Python takes the opposite route — it 
cloudpickles the exception and re-raises the typed object 
(`flink_runner_context.py:474`, `:442`) — as written would the same `Outcome` 
report a recovered timeout as `TIMED_OUT` in Python and `FAILED` in J
 ava? Is that one contract for both languages, or is the divergence acceptable 
for v1?

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

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

Reply via email to