[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
Mantenedores costumam responder em até 2 dias
Avaliação
Esta issue ainda não foi avaliada.
Descrição
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
- Serve an agent behind SSE; start a streaming run with a slow/long model response (or a multi-round tool loop).
- Disconnect the SSE client mid-generation and dispose the event-flow subscription.
- 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):
- 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 - Expose a first-class cancellation handle per run/invocation, and document that model loops should check it at chunk/round boundaries (cooperative cancellation), or
- At minimum, document the current behavior prominently — today it silently leaks billable model calls.
- Linguagem predominante
- Java
- Estrelas
- 1.8k
- Forks
- 446
- Merge médio
- 5d 3h
- PRs com merge (30d)
- 68
Preparar o ambiente
Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.
- Sem Dockerfile nem arquivo Docker Compose
- Tem um modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de google/adk-java
-
GeminiUtil placeholder user turn ("Continue output. DO NOT look at this line ...") is flagged by prompt injection filtersTalvez já em andamento @hemasekhar-p assumiu há 14 dias. Abertaneeds review
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 76/100
google/adk-java#1628 · 1 comentário · 1 responsável ·
Mantenedores costumam responder em até 2 dias
-
[spring-ai] Streaming responses ending with CJK punctuation (。!?) are misclassified as partial and never persisted to the sessionTalvez já em andamento @hirematha assumiu há 17 dias. Abertaneeds review
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
google/adk-java#1608 · 3 comentários · 1 responsável ·
Mantenedores costumam responder em até 2 dias
-
McpToolset hangs silently for ~5 minutes per retry (3 retries) when stdio command is an npm shim ("npx") on WindowsTalvez já em andamento @hemasekhar-p assumiu hoje. Aberta
google/adk-java#1686 · 1 comentário · 1 responsável ·
Mantenedores costumam responder em até 2 dias
-
runLive passes partial events to appendEvent and never aggregates text chunks, unlike ADK PythonTalvez já em andamento @hemasekhar-p assumiu há 10 dias. Abertaneeds review
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 45/100
google/adk-java#1648 · 3 comentários · 1 responsável ·
Mantenedores costumam responder em até 2 dias
-
FirestoreSessionService compares event timestamps as text, reordering or skipping same-second eventsTalvez já em andamento @hemasekhar-p assumiu há 10 dias. Abertaneeds review
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 50/100
google/adk-java#1646 · 3 comentários · 1 responsável ·
Mantenedores costumam responder em até 2 dias
Todas as issues de google/adk-java
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 79/100
checkstyle/checkstyle#22145 ·
Mantenedores costumam responder em até 1 dia
-
rset command throws NPE in ResultsFormat.guessSyntaxTalvez já em andamento @Ostrzyciel assumiu hoje. Abertabug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 1 dia
-
enhancement good first issue help wanted
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 83/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
objectionary/eo#9593 ·
Mantenedores costumam responder em até 1 dia
-
release bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
OpenLiberty/open-liberty#36124 ·
Mantenedores costumam responder em até 1 dia