Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#1,556 1 Kommentar 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@hemasekhar-p arbeitet bereits daran.

Seit 25.9.2026.

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

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
Vorherrschende Sprache
Java
Sterne
1.7k
Forks
421
Ø Merge
3 T. 9 Std.
Gemergte PRs (30 T.)
29

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus google/adk-java

Alle Issues in google/adk-java

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.