wang-jiahua opened a new issue, #1358: URL: https://github.com/apache/rocketmq-clients/issues/1358
### Programming Language of the Client Golang ### Runtime Platform Environment Any (found by static analysis + verified on macOS / Linux, Go 1.26) ### RocketMQ Version of the Client/Server golang client master (v5) ### Describe the Bug `go vet ./...` reports 13 `lostcancel` findings in the golang client: 11 unary RPC wrappers in `client_manager.go`, the dial timeout in `conn.go`, and `Telemetry` all call `context.WithTimeout(...)` and discard the returned cancel function (`ctx, _ = context.WithTimeout(ctx, duration)`). Two consequences: 1. For the unary RPCs and dial: every call leaks the timeout timer and derived context until the deadline expires. The RPC itself usually returns long before that, so under high call rates (send/heartbeat/ack/query) the runtime accumulates pending timers that serve no purpose. It also means any module enabling `go vet` in CI fails on these files. 2. For `Telemetry` the problem is behavioral: it returns a long-lived bidirectional stream that is cached in `clientSettings.observer`, but the per-call timeout kills that stream every `timeout` interval, forcing the recv loop to tear down and rebuild it periodically. ### Steps to Reproduce Run `go vet ./...` in the `golang` directory: 13 lostcancel findings. ### What Did You Expect to See? `cancel` released as soon as each unary call returns; the cached telemetry stream not being killed by an artificial per-call deadline; `go vet` clean. ### What Did You See Instead? 13 lostcancel findings; telemetry stream rebuilt every `cs.timeout`. ### Additional Context Fix incoming: `defer cancel()` for the 11 unary RPCs and the dial path; remove the per-call timeout on the persistent `Telemetry` stream (matching how the other streaming RPC `ReceiveMessage` handles its context). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
