Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Bug]: REST transport never signals normal stream completion to the client (SSE hangs until timeout)

Abierto
  • ¿Algo no está bien?
#1,194 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@SashaMIT ya está trabajando en esto.

Desde el 9/10/2026.

  • #1202 de @hutiefang76 — abierto
  • #1209 de @SashaMIT — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java
Área
api, backend

Línea de trabajo

Start with RestTransport.sendMessageStreaming and the A2AHttpClient postAsyncSSE/getAsyncSSE completion callbacks, then compare the JSON-RPC listener behavior described in the issue. Trace how ClientTransport exposes stream outcomes and how the returned CompletableFuture could support cancellation. Done means REST streams report exactly one normal completion or error and in-flight streams can be released.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What happened?

What happened?

On the REST (HTTP+JSON) client transport, a streaming call (sendMessage / sendMessageStreaming, resubscribe) never delivers a normal-completion signal to the caller. When the remote finishes a stream cleanly, the client's Flow.Publisher / SSE consumer stays open until it times out, even though the upstream connection has already ended.

The JSON-RPC transport does not surface this the same way: its listener turns the connection-end into a terminal errorHandler(null) completion signal. RestTransport does not do the equivalent, so a REST client has no way to observe that a stream completed normally.

Root cause (as far as we traced it)

The HTTP layer already carries a completion callback — A2AHttpClient's postAsyncSSE / getAsyncSSE accept a completeRunnable. But:

  • RestTransport.sendMessageStreaming passes a no-op for that completeRunnable and discards the returned CompletableFuture, so the transport neither forwards the "stream ended" signal nor retains a handle to the stream.
  • close() on the REST transport is a no-op, so a client cannot release the upstream connection that way either.

The completion signal therefore exists at the HTTP layer and is dropped at the transport layer, never reaching ClientTransport / the client. This is the same no-op REST completion callback that #1170 / #1173 explicitly scoped out when fixing the duplicate-terminal-callback contract for the JSON-RPC listeners: #1170 says to "evaluate REST separately: its native and 0.3 implementations currently both use a no-op completion callback, so changing that is an API decision rather than a compat-only fix," and #1173 left REST as is on those grounds. This issue is to track that deferred REST decision.

Note the signal that's missing is "the connection ended," not "a terminal event arrived." Terminal-event detection alone is insufficient, because a stream can legitimately end with no final event — e.g. an interrupted state (input-required / auth-required), which per #975 / #756 is deliberately non-terminal and keeps the stream open. Those streams close only on connection-end.

Expected behavior

A REST streaming client should be able to observe exactly one terminal outcome per stream — a normal completion or an error — the way the JSON-RPC path does after #1173, and should be able to cancel/release an in-flight stream.

Actual behavior

Normal completion is silently dropped. A stream that ends without a terminal event (or whose terminal event the client isn't watching for) hangs until the caller's own SSE/emitter timeout fires.

Steps to reproduce

  1. Build a client against an agent whose card selects the REST (HTTP+JSON) transport.
  2. Start a streaming request (sendMessage streaming or resubscribe) against a remote that ends the stream by closing the connection without a final TaskStatusUpdateEvent — e.g. a turn that ends on input-required.
  3. Observe that the client's stream never completes; it stays open until timeout.

Workaround

Decorate the A2AHttpClient for one stream's duration: wrap the completeRunnable handed to postAsyncSSE / getAsyncSSE so connection-end fires a caller-visible callback, and retain the returned CompletableFuture so the stream can be cancelled on caller disconnect. This recovers both capabilities the transport drops, but it reaches around the SDK for something the transport could expose directly.

Proposed fix

Thread the existing HTTP-layer completion callback through RestTransport and expose it on ClientTransport, mirroring what JSON-RPC effectively does after #1173. This is additive and backward-compatible — callers that don't supply a completion handler are unaffected. (@scarvel8 offered a similar PR in #310.)

Related

  • #310 — feature request for a stream-completion callback (transport-agnostic); this issue is the REST-transport-specific bug behind it.
  • #1170 / #1173 — fixed the JSON-RPC SSE terminal-callback contract and explicitly deferred REST as an API decision (#1170: "evaluate REST separately ... a no-op completion callback ... an API decision").
  • #975 / #756 — interrupted states are intentionally non-terminal, which is why connection-end (not terminal-event detection) is the signal that must be exposed.
Relevant log output
Code of Conduct
  • I agree to follow this project's Code of Conduct
Lenguaje dominante
Java
Estrellas
504
Forks
184
Merge medio
1 d 13 h
PR fusionados (30 d)
31

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de a2aproject/a2a-java

Todos los issues de a2aproject/a2a-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.