Evaluate non-blocking stream client close behavior in Triple runtime

[Alanxtl]

Background

Dubbo-go Triple is built on a forked and heavily modified copy of connect-go runtime code under protocol/triple/triple_protocol. We do not depend on upstream connect-go directly anymore, but the core stream client lifecycle still follows the same general design.

Because of that, upstream connect-go runtime fixes can still be relevant when they address stream lifecycle behavior rather than Connect-specific product features. In connect-go v1.18.0, upstream changed stream client closures to be non-blocking (connectrpc/connect-go#791). Dubbo-go Triple has corresponding APIs such as ClientStreamForClient.CloseAndReceive, BidiStreamForClient.CloseRequest, BidiStreamForClient.CloseResponse, and the underlying duplexHTTPCall lifecycle.

Blocking close behavior can be painful in Dubbo-go because a stream sample or integration test may hang when one side stops reading/writing, a transport error happens, or the server returns an error before the client finishes sending.

Scope

• Compare Dubbo-go Triple stream close behavior with the upstream non-blocking close change.
• Add focused tests for close paths when the peer has already errored, stopped reading, or returned early.
• Port only the relevant lifecycle behavior if our current close path can block unnecessarily.

Notes

This should stay narrowly scoped to stream close lifecycle behavior. It should selectively backport useful runtime behavior from the modified connect-go lineage, not pull in unrelated connect-go additions such as package_suffix, HTTP GET support, or transport-level retry.

Reference: https://github.com/connectrpc/connect-go/releases/tag/v1.18.0

[Alanxtl]

先看一下我们目前的流式传输支不支持这个能力

[Vanillaxi]

目前 Dubbo-go Triple 还没有完整支持 connect-go v1.18.0 中的 non-blocking close 行为，receive side close路径仍然有不必要阻塞的风险。

• ClientStreamForClient.CloseAndReceive 会依次调用 CloseRequest、接收 unary response、再调用 CloseResponse。
• ServerStreamForClient.Close 和 BidiStreamForClient.CloseResponse 最终都会走到 conn.CloseResponse。
• BidiStreamForClient.CloseRequest 最终走的是 conn.CloseRequest。
• CloseRequest 当前相对安全，因为底层是duplexHTTPCall.CloseWrite()，主要是启动请求并关闭 request pipe writer。但 CloseResponse 目前不是非阻塞的。它最终会走到 duplexHTTPCall.CloseRead()，而 CloseRead 当前会先等待 responseReady，然后通过 discard(response.Body) 尝试 drain response body，最后再 close body。这个行为和 connect-go #791 修复前的旧逻辑一致。虽然 discard 有 4MiB 限制，但如果对端不继续发送响应 body，仍然可能阻塞在读取 response body上。

建议方案：

1. 先补针对性的回归测试：
   • server-stream：服务端发送一条消息后保持响应不结束，客户端 Receive 一条后调用 Close，断言 Close 能快速返回。
   • bidi-stream：服务端提前返回或停止读取，客户端调用 CloseResponse，断言不会阻塞。
   • client-stream：服务端在客户端发送完成前提前返回 error，客户端 CloseAndReceive 应能拿到错误并完成清理，不应 hang。
   • 可以额外加一个 duplexHTTPCall 级别的小测试，用阻塞的 response body 验证 CloseRead 不再 drain body。
2. 只回迁和生命周期相关的行为：
   • 修改 duplexHTTPCall.CloseRead()，不再在 close 时 discard/drain response.Body。
   • response ready 后直接关闭 response.Body。
   • 保留 Receive 路径读取到 EOF 后解析 trailers 的行为。如果用户需要最终 trailers/status，应该继续 Receive 到 EOF，而不是依赖 CloseResponse 来 drain。

[Alanxtl]

目前 Dubbo-go Triple 还没有完整支持 connect-go v1.18.0 中的 non-blocking close 行为，receive side close路径仍然有不必要阻塞的风险。

• ClientStreamForClient.CloseAndReceive 会依次调用 CloseRequest、接收 unary response、再调用 CloseResponse。
• ServerStreamForClient.Close 和 BidiStreamForClient.CloseResponse 最终都会走到 conn.CloseResponse。
• BidiStreamForClient.CloseRequest 最终走的是 conn.CloseRequest。
• CloseRequest 当前相对安全，因为底层是duplexHTTPCall.CloseWrite()，主要是启动请求并关闭 request pipe writer。但 CloseResponse 目前不是非阻塞的。它最终会走到 duplexHTTPCall.CloseRead()，而 CloseRead 当前会先等待 responseReady，然后通过 discard(response.Body) 尝试 drain response body，最后再 close body。这个行为和 connect-go how to make sure consul register service mata map's value length >= 512 #791 修复前的旧逻辑一致。虽然 discard 有 4MiB 限制，但如果对端不继续发送响应 body，仍然可能阻塞在读取 response body上。

建议方案：

1. 先补针对性的回归测试：

   • server-stream：服务端发送一条消息后保持响应不结束，客户端 Receive 一条后调用 Close，断言 Close 能快速返回。
   • bidi-stream：服务端提前返回或停止读取，客户端调用 CloseResponse，断言不会阻塞。
   • client-stream：服务端在客户端发送完成前提前返回 error，客户端 CloseAndReceive 应能拿到错误并完成清理，不应 hang。
   • 可以额外加一个 duplexHTTPCall 级别的小测试，用阻塞的 response body 验证 CloseRead 不再 drain body。

2. 只回迁和生命周期相关的行为：

   • 修改 duplexHTTPCall.CloseRead()，不再在 close 时 discard/drain response.Body。
   • response ready 后直接关闭 response.Body。
   • 保留 Receive 路径读取到 EOF 后解析 trailers 的行为。如果用户需要最终 trailers/status，应该继续 Receive 到 EOF，而不是依赖 CloseResponse 来 drain。

看起来没问题，assign 给你了
另外trailer这块还有个pr没有合并，你实现的时候别冲突了 #3446