Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,194 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

@SashaMIT y travaille déjà.

Depuis le 9/10/2026.

  • #1202 par @hutiefang76 — ouverte
  • #1209 par @SashaMIT — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
java
Domaine
api, backend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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
Langage dominant
Java
Étoiles
507
Forks
192
Merge moyen
1 j 19 h
PR mergées (30 j)
22

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de a2aproject/a2a-java

Toutes les issues de a2aproject/a2a-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.