[Bug][runtime] Interrupted tool calls are recorded as tool errors, letting the action loop continue and persist as completed
- Dominant language
- Java
- Stars
- 452
- Forks
- 167
- Avg merge
- 5d 9h
- Merged PRs (30d)
- 49
Description
## Description
`RunnerContextImpl.executeSequentially`/`executeParallel`'s tool-call path (`ToolCallAction.java:256`) catches `InterruptedException` the same as any ordinary tool failure, records it as a tool error, and lets the action loop continue — unlike the chat-call path (fixed in #1071), which now rethrows a raw `InterruptedException` immediately.
Concretely, on a cancellation during a tool call:
1. `ToolCallAction.java:256` catches the `InterruptedException`, `:257` records it as a tool error.
2. The loop moves on and (`:85`) sends the `ToolResponseEvent` anyway, which drives another chat call.
3. `ActionExecutionOperator` then persists the action as completed (~line 491, `durableExecManager.maybePersistTaskResult`), since nothing tells it the action was actually interrupted.
4. On recovery, `actionState.isCompleted()` (~line 437) skips re-execution and replays that stale output instead of re-running the call.
Step 4 is the same failure mode as #1070's "problem 2" (a stale interruption replayed as terminal after recovery), just reached through the action-state persistence path instead of the durable-call-slot path that #1071 closed for the chat side — because here the raw `InterruptedException` never escapes far enough to skip the persist call.
`executeParallel` has the equivalent shape at `RunnerContextImpl.java:209` (parallel tool call execution added in #926).
This predates #1071 and is out of that PR's scope (chat-call retry/persistence only); filing separately per discussion on https://github.com/apache/flink-agents/pull/1071#discussion_r3892137335 and follow-up at https://github.com/apache/flink-agents/pull/1071#discussion_r3915950776.
## Expected behavior
A cancellation during a tool call should propagate the same way the chat-call fix in #1071 does: restore the interrupt flag and rethrow immediately, rather than being recorded as a tool error and let the action loop continue — so the action is never persisted as completed off the back of a cancelled tool call, and recovery re-executes rather than replaying stale output.
## Are you willing to submit a PR?
- [x] I'm willing to submit a PR!
Contributor guide
Assessment
This issue has not been assessed yet.