Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,194 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@SashaMIT đang làm issue này rồi.

Từ ngày 9/10/2026.

  • #1202 của @hutiefang76 — đang mở
  • #1209 của @SashaMIT — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
api, backend

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
Java
Star
505
Fork
185
Merge trung bình
1 ngày 9 giờ
Pull request đã merge (30 ngày)
26

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của a2aproject/a2a-java

Tất cả issue của a2aproject/a2a-java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.