Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#1,194 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@hutiefang76 がすでに取り組んでいます。

2026年10月4日 から。

  • #1202 @hutiefang76 による — オープン
  • #1209 @SashaMIT による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
java
領域
api, backend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
Java
スター
504
フォーク
184
平均マージ
1日 13時間
マージ済み PR（30日）
31

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

a2aproject/a2a-java のほかの issue

a2aproject/a2a-java の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。