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

[core] Client disconnects don't cancel the model stream (per-step flow is cached) — and there is no public API to cancel an in-flight run

未關閉
#1,618 6 則留言 0 個 reaction 已指派 1 人 在 GitHub 檢視

維護者通常 1 天內回覆

@hemasekhar-p 已經在處理了。

開始於 2026年10月6日。

  • #1621 來自 @sangkyoonnam —— 未關閉

評估

這個 Issue 還沒有評估資料。

描述

needs review
Describe the Bug

When a client disconnects while an agent is streaming (e.g. the SSE consumer cancels its subscription to Runner's event flow), the underlying model call keeps running to completion. Tokens continue to be billed with no consumer attached. In one production incident the model kept generating for 3+ minutes after the client went away (observed via gateway-side logs and token metering).

The cause appears to be BaseLlmFlow.java line 530 (main at the time of writing):

Flowable<Event> currentStepEvents = runOneStep(spanContext, invocationContext).cache();

With RxJava cache(), the upstream connection is only disposed when all subscribers of the cached flow cancel. As long as any subscriber attached by the framework itself (event handling/aggregation within the invocation) is alive, a user-side cancellation cannot reach the model stream.

On top of that, there is no public API to cancel an in-flight run: neither Runner nor InvocationContext nor the session exposes a "stop generating" handle. The only way to stop a long generation is to let it finish.

To Reproduce
  1. Serve an agent behind SSE; start a streaming run with a slow/long model response (or a multi-round tool loop).
  2. Disconnect the SSE client mid-generation and dispose the event-flow subscription.
  3. Observe on the model/gateway side (or via token metering) that generation continues until the model finishes naturally.
Expected behavior

Cancelling the downstream subscription (or any public cancellation entry point) must reach the model stream: the in-flight LLM request is disposed (or aborted at the next chunk/round boundary), and no further rounds are started.

Environment
  • google/adk-java main (1.11.1-SNAPSHOT at the time of writing)
  • Spring AI bridge + SSE transport, but the cache() behavior is in core (BaseLlmFlow) and should affect any transport
Additional context

In production we could only implement "stop generating" with a cooperative cancellation protocol outside the framework: a per-run cancel flag (REST endpoint sets it) that the model-stream loop checks at every chunk and at tool-round boundaries, plus setCancellable hooks for the current round. It works, but it is entirely application-side — the framework neither propagates the cancellation nor offers a canonical way to express it.

Suggested directions (happy to discuss or contribute):

  1. Replace the unbounded cache() with cancellation-propagating semantics (e.g. publish().refCount()-style sharing, or a scoped subscription that disposes the source when the invocation ends/cancels), or
  2. Expose a first-class cancellation handle per run/invocation, and document that model loops should check it at chunk/round boundaries (cooperative cancellation), or
  3. At minimum, document the current behavior prominently — today it silently leaks billable model calls.
主要語言
Java
星號
1.7k
分支
433
平均合併
3 天 9 小時
30 天內合併 PR
46

環境準備

在 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 摘要。