Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Approved tool call re-runs on every later user turn if it never got a function response

オープン
#1,556 コメント 1 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@hemasekhar-p がすでに取り組んでいます。

2026年9月25日 から。

評価

この issue はまだ評価されていません。

説明

needs review

🔴 Required Information

Describe the Bug:

RequestConfirmationLlmRequestProcessor runs before every LLM call and looks for the user's answer to a tool confirmation. findMostRecentConfirmations walks the session backwards past every user event that carries no adk_request_confirmation response: plain text turns, and turns that answer other function calls. An approval given several turns earlier is therefore found again on every later LLM call.

The processor then skips the calls in alreadyResumedIds, which only holds calls that got a function response from this agent after the approval. If the approved call never got one, the processor runs the tool again with its original arguments when the next, unrelated user message arrives, and on every later turn, until a function response for that call is saved.

One way to get there: the resumed call fails asynchronously, for example a custom BaseTool whose runAsync throws or returns a failing Single, or a FunctionTool method that returns a Single or Maybe that errors, and no onToolErrorCallback on the agent or a plugin supplies a response. processRequest then logs the error in onErrorReturn and returns no event, so no function response is saved. A synchronous exception from a FunctionTool method does not take this path: FunctionTool.runAsync catches it and returns an error response, which is saved.

Steps to Reproduce:

  1. Take the CONFIRMED_CALL_EVENTS fixture in RequestConfirmationLlmRequestProcessorTest: the agent calls echo_tool with {"say": "hello"}, the tool's response asks for confirmation, the agent calls adk_request_confirmation, and the user approves it with {"confirmed": true}. No echo_tool response follows the approval.
  2. Append a plain text user event ("unrelated follow-up question").
  3. Call processRequest for the agent that owns echo_tool (code below).

Expected Behavior:

No events. The latest user event does not answer the confirmation, so there is nothing to resume. ADK Python's processor reads only the last user-authored event and returns when it has no function responses (_confirmation.py L276-L298).

Observed Behavior:

processRequest returns one event from test agent with the part {"functionResponse":{"id":"original_fc_id","name":"echo_tool","response":{"result":{"say":"hello"}}}}: echo_tool ran with its original arguments, on the approval from the earlier turn. The same happens when the latest user event answers some other function call instead of sending text.

Environment Details:

  • ADK Library Version (see maven dependency): 1.10.1 (same code path, checked by diff); reproduced on main at 4092a1f
  • OS: Windows 11 (the code path does not depend on the OS)
  • TS Version (tsc --version): N/A (Java: Microsoft OpenJDK 17.0.19; Maven 4.0.0-rc-3 via mvnw)

Model Information:

  • Which model is being used: N/A. The processor runs before the model is called; the reproduction uses the test LLM.

🟡 Optional Information

Regression:

No. The processor has looked past later user events for an approval since at least 0.6.0 (9611f89, which introduced the current backward scan). The check that skips already-executed calls came with that scan as alreadyConfirmedIds; 1.8.0 (e5aba3a) renamed it alreadyResumedIds and limited it to this agent's own responses. Either way it only covers calls that did get a function response.

Logs:

The two tests added in #1534, run against the unchanged processor on main (ids and trailing fields shortened):

[ERROR]   RequestConfirmationLlmRequestProcessorTest.runAsync_laterUserTurnAnswersOtherFunctionCall_doesNotCallOriginalFunction:263 value of: resumedEvents(...)
expected to be empty
but was : [{"id":"…","invocationId":"…","author":"test agent","content":{"parts":[{"functionResponse":{"id":"original_fc_id","name":"echo_tool","response":{"result":{"say":"hello"}}}}],"role":"user"},…}]
[ERROR]   RequestConfirmationLlmRequestProcessorTest.runAsync_userTextTurnAfterApproval_doesNotCallOriginalFunction:231 value of: resumedEvents(...)
expected to be empty
but was : [{"id":"…","invocationId":"…","author":"test agent","content":{"parts":[{"functionResponse":{"id":"original_fc_id","name":"echo_tool","response":{"result":{"say":"hello"}}}}],"role":"user"},…}]
[ERROR] Tests run: 17, Failures: 2, Errors: 0, Skipped: 0

Additional Context:

The fix and regression tests are in #1534: the scan stops at the most recent user event, as in ADK Python. This issue covers the approval carrying over into later user turns. Within the invocation that answered the confirmation, the approval is still the latest user event, so re-applying it on that invocation's later LLM calls is out of scope here.

This was first observed in an application with a requireConfirmation tool: a user approved a pending call, the resumed execution was aborted, and the next unrelated question re-ran the tool with the original arguments.

Minimal Reproduction Code:

Add to RequestConfirmationLlmRequestProcessorTest on main. It only uses the class's existing fixtures and helpers:

@Test
public void runAsync_userTextTurnAfterApproval_doesNotCallOriginalFunction() {
  LlmAgent agent = createAgentWithEchoTool();
  Event laterUserTextEvent =
      Event.builder()
          .author("user")
          .content(Content.fromParts(Part.fromText("unrelated follow-up question")))
          .build();
  Session session =
      Session.builder("session_id")
          .events(
              ImmutableList.<Event>builder()
                  .addAll(CONFIRMED_CALL_EVENTS)
                  .add(laterUserTextEvent)
                  .build())
          .build();

  // Fails on main: the earlier approval runs echo_tool again.
  assertThat(resumedEvents(agent, session)).isEmpty();
}

Run it with ./mvnw -pl core test -Dtest=RequestConfirmationLlmRequestProcessorTest.

How often has this issue occurred?:

  • Always (100%) with the event sequence above
主要言語
Java
スター
1.7k
フォーク
421
平均マージ
3日 15時間
マージ済み PR(30日)
32

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

google/adk-java のほかの issue

google/adk-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。