Runner drops callbackContextData written in onUserMessageCallback when it resumes an invocation
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 78/100
Direzione di ricerca
Leggi runResumedAgent, resumeCore e runAgentWithUpdatedSession nell’implementazione di Runner. Segui come viene costruito initialContext e passato ai callback, quindi confronta il percorso di ripresa con quello di una nuova invocazione. Riproduci il problema con la ripresa abilitata e un plugin che memorizza dati in onUserMessageCallback; il lavoro è completato quando i callback dell’agente ripreso vedono quei dati e un test di regressione copre il comportamento di ripresa esistente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Please make sure you read the contribution guide and file the issues in the right place.
Contribution guide.
🔴 Required Information
Describe the Bug
InvocationContext.callbackContextData() is "a map for storing temporary context data that can be shared
between different parts of the invocation", and InvocationContext.Builder passes the same instance to every
copy "so that Plugins can access the same data … across all types of callbacks."
A new invocation keeps that promise. runNewInvocation runs onUserMessageCallback on initialContext, and
runAgentWithUpdatedSession builds the agent's context with initialContext.toBuilder(), so the map is shared.
A resumed invocation does not. resumeCore runs onUserMessageCallback on its own initialContext, but
runResumedAgent is not given that context and builds the agent's from a second builder:
// runResumedAgent
InvocationContext rootContext =
newInvocationContextBuilder(session, rootAgent)
.invocationId(resolvedInvocationId)
.runConfig(runConfig)
.userContent(userContentFor(session, resolvedInvocationId, userContent))
.build();
newInvocationContextBuilder starts a new, empty callbackContextData, so whatever a plugin stored in
onUserMessageCallback is missing from beforeRunCallback and from every callback that runs with the agent.
The same builder also resets endInvocation: a plugin that ends the invocation in onUserMessageCallback stops
a new invocation, but a resumed one still calls the model. On every resume, onRunErrorCallback also runs on
initialContext, so it does not see what beforeRunCallback stored, even when no new message is sent.
Trigger: resumability enabled and an invocation paused (for example on a long-running tool) that is then
resumed, with or without a new message. New invocations are unaffected.
Steps to Reproduce
- A
RunnerwithResumabilityConfig.builder().resumable(true), anLlmAgentwith a long-running tool, and a
plugin whoseonUserMessageCallbackputs a value intoinvocationContext.callbackContextData()and whose
beforeAgentCallbackreads it back. - Send a message. The model calls the tool and the invocation pauses.
- Send the tool's function response, which resumes the invocation.
Expected Behavior
On the resumed turn, beforeAgentCallback reads the value that turn's onUserMessageCallback stored, as it
does on the first turn.
Observed Behavior
The first turn reads its value, and the resumed turn reads null (the plugin stores message-1, then
message-2). beforeAgentCallback reads, per turn:
[agent:message-1, agent:null]
The same happens when the resume is routed to a sub-agent instead of the root.
Environment Details
- ADK Library Version:
main@84bae34a(pom 1.13.0) - OS: not OS-specific
- TS Version: N/A (Java)
Model Information
N/A
🟡 Optional Information
Regression
No. Present since resuming an invocation was added (v1.11.0).
Willingness to contribute
Yes, a PR follows. runResumedAgent takes initialContext and builds the agent's context with
initialContext.toBuilder(), as runAgentWithUpdatedSession does:
InvocationContext rootContext =
initialContext.toBuilder()
.agent(rootAgent)
.userContent(...)
.build();
How often has this issue occurred?
Always (100%), on a resumed invocation.
- Lingua principale
- Java
- Stelle
- 1.8k
- Fork
- 440
- Merge medio
- 3g 16h
- PR unite (30g)
- 92
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di google/adk-java
-
InMemorySessionService.appendEvent recreates a deleted sessionForse già presa @hirematha l’ha presa 4 giorni fa. Apertaneeds review
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
google/adk-java#1697 · 2 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
AgentExecutor ignores the A2A contextId when creating a session, so multi-turn conversations start over every turnForse già presa @hirematha l’ha presa 2 giorni fa. Apertaneeds review
google/adk-java#1718 · 2 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
McpToolset hangs silently for ~5 minutes per retry (3 retries) when stdio command is an npm shim ("npx") on WindowsForse già presa @hemasekhar-p l’ha presa 8 giorni fa. Apertaneeds review
google/adk-java#1686 · 4 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
runLive passes partial events to appendEvent and never aggregates text chunks, unlike ADK PythonForse già presa @hemasekhar-p l’ha presa 18 giorni fa. Apertaneeds review
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
google/adk-java#1648 · 3 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
FirestoreSessionService compares event timestamps as text, reordering or skipping same-second eventsForse già presa @hemasekhar-p l’ha presa 18 giorni fa. Apertaneeds review
Difficoltà 3/5 1-2 giorni Idoneità per principianti 50/100
google/adk-java#1646 · 3 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di google/adk-java
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
bug/错误
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
FCL-Team/FoldCraftLauncher#1982 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
[BUG] micronaut-serde-oracle-jdbc-json brings a second OJDBC driver onto the runtime classpathForse già presa @ZARAYACH l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
micronaut-projects/micronaut-serialization#1494 · 4 commenti ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 75/100
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
I maintainer di solito rispondono entro 2 giorni