Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Runner drops callbackContextData written in onUserMessageCallback when it resumes an invocation

未關閉 適合新手
#1,695 1 則留言 0 個 reaction 已指派 1 人 在 GitHub 檢視

維護者通常 1 天內回覆

@hirematha 已經在處理了。

開始於 2026年10月26日。

  • #1696 來自 @svetanis —— 未關閉

評估

難度
2/5
預估耗時
1-3 小時
新手友好度
78/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
java
領域
backend

研究方向

閱讀 Runner 實作中的 runResumedAgent、resumeCore 和 runAgentWithUpdatedSession。追蹤 initialContext 的建立方式及其如何傳遞給回呼,然後比較恢復路徑與新呼叫路徑。啟用可恢復功能,並使用一個在 onUserMessageCallback 中儲存資料的外掛程式來重現;當恢復後的 agent 回呼能看到這些資料,且現有的恢復行為由回歸測試涵蓋時,即為完成。

由索引模型根據 Issue 內容生成。

描述

needs review

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
  1. A Runner with ResumabilityConfig.builder().resumable(true), an LlmAgent with a long-running tool, and a
    plugin whose onUserMessageCallback puts a value into invocationContext.callbackContextData() and whose
    beforeAgentCallback reads it back.
  2. Send a message. The model calls the tool and the invocation pauses.
  3. 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.

主要語言
Java
星號
1.8k
分支
440
平均合併
3 天 22 小時
30 天內合併 PR
88

環境準備

在 Codespaces 中開啟

在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

google/adk-java 的其他 Issue

查看 google/adk-java 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。