You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "wang-jiahua (via GitHub)" <gi...@apache.org> on 2026/09/03 09:05:23 UTC
[I] [Bug] Golang client discards context.WithTimeout cancel functions (13 go vet lostcancel findings; Telemetry stream killed periodically) [rocketmq-clients]
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: commits-unsubscribe@rocketmq.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Bug] Golang client discards context.WithTimeout cancel functions (13 go vet lostcancel findings; Telemetry stream killed periodically) [rocketmq-clients]
Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #1358:
URL: https://github.com/apache/rocketmq-clients/issues/1358#issuecomment-5524060075
**Issue Evaluation**
Category: `bug` | Status: **Confirmed**
The `lostcancel` findings from `go vet` are valid. Discarding the cancel function from `context.WithTimeout()` causes:
1. **Timer leak (11 unary RPCs + dial):** Each call leaks the timeout timer until the deadline expires. Under high call rates (send/heartbeat/ack), this accumulates unnecessary pending timers.
2. **Telemetry stream disruption:** The per-call timeout kills the cached bidirectional stream every `timeout` interval, forcing periodic teardown and rebuild — a behavioral bug beyond just a resource leak.
**Root Cause:** `ctx, _ = context.WithTimeout(ctx, duration)` pattern in `client_manager.go` (11 unary wrappers), `conn.go` (dial), and `Telemetry` stream setup.
**Impact:** Resource leak under load; Telemetry stream instability; CI failure if `go vet` is enabled.
**Severity:** high (affects production stability under load, Telemetry correctness)
The proposed fix (`defer cancel()` for unary RPCs, removing per-call timeout on persistent Telemetry stream) is correct and aligns with how `ReceiveMessage` handles its context.
---
*Automated evaluation by github-manager*
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Bug] Golang client discards context.WithTimeout cancel functions (13 go vet lostcancel findings; Telemetry stream killed periodically) [rocketmq-clients]
Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #1358:
URL: https://github.com/apache/rocketmq-clients/issues/1358#issuecomment-5655082147
**Issue Evaluation**
Category: `type/bug` | Status: **Confirmed**
The 13 `lostcancel` findings are real and have two distinct impacts:
1. **Timer/context leaks** (11 unary RPCs + dial): Every call to `context.WithTimeout` without storing the cancel function leaks the timer until the deadline expires. Under high call rates, this accumulates unnecessary pending timers.
2. **Telemetry stream killed periodically**: The per-call timeout on the bidirectional stream causes the cached `clientSettings.observer` to be torn down and rebuilt every `timeout` interval, which is a behavioral bug beyond just a vet warning.
The fix is straightforward: store and defer the cancel function in each unary RPC wrapper, and for Telemetry, either remove the per-call timeout or apply it only to the initial dial (not the long-lived stream).
---
*Automated evaluation by github-manager*
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Bug] Golang client discards context.WithTimeout cancel functions (13 go vet lostcancel findings; Telemetry stream killed periodically) [rocketmq-clients]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on issue #1358:
URL: https://github.com/apache/rocketmq-clients/issues/1358#issuecomment-6159593666
This issue is stale because it has been open for 30 days with no activity. It will be closed in 3 days if no further activity occurs.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Bug] Golang client discards context.WithTimeout cancel functions (13 go vet lostcancel findings; Telemetry stream killed periodically) [rocketmq-clients]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] closed issue #1358: [Bug] Golang client discards context.WithTimeout cancel functions (13 go vet lostcancel findings; Telemetry stream killed periodically)
URL: https://github.com/apache/rocketmq-clients/issues/1358
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Bug] Golang client discards context.WithTimeout cancel functions (13 go vet lostcancel findings; Telemetry stream killed periodically) [rocketmq-clients]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on issue #1358:
URL: https://github.com/apache/rocketmq-clients/issues/1358#issuecomment-6243847023
This issue was closed because it has been inactive for 3 days since being marked as stale.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org