Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,556 1 commentaire 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@hemasekhar-p y travaille déjà.

Depuis le 25/9/2026.

Évaluation

Cette issue n'a pas encore été évaluée.

Description

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
Langage dominant
Java
Étoiles
1.7k
Forks
421
Merge moyen
3 j 14 h
PR mergées (30 j)
31

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de google/adk-java

Toutes les issues de google/adk-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.