apache / apache/flink-agents

[Bug][runtime] Interrupted tool calls are recorded as tool errors, letting the action loop continue and persist as completed

Closed
#1,088 0 comments 0 reactions 1 assignee Claimed by @Ashfaqbs View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.