RockteMQ-AI commented on issue #1323: URL: https://github.com/apache/rocketmq-clients/issues/1323#issuecomment-5370336454
Hi @AndyLvVip, thanks for reporting this! I've analyzed this issue against the codebase and can confirm this appears to be a **real bug**. **Root Cause:** In `golang/process_queue.go` (lines 468-471), the `isNoNewMessage` branch (handling `Code_MESSAGE_NOT_FOUND` from expired long-polling) only logs at debug level and does not call `cli.doAfter(MessageHookPoints_RECEIVE, ...)`. Since the matching `doBefore(MessageHookPoints_RECEIVE, ...)` was already called at line 449 (incrementing the counter), the inflight counter `inflightReceiveRequestCount` is never decremented on this path, leaking one count per expired long-poll. **Affected Files:** golang/process_queue.go, golang/push_consumer.go **Analysis:** The `defultInflightRequestCountInterceptor` (push_consumer.go:697) increments in `doBefore` and decrements in `doAfter` for `MessageHookPoints_RECEIVE`. The success path (line 460) and the generic-error path (line 473) both call `doAfter`, but the `MESSAGE_NOT_FOUND` branch (line 469) skips it. As a result, `waitingReceiveRequestFinished` (push_consumer.go:550) can never observe a zero counter and always waits the full `requestTimeout + longPollingTimeout`, then `GracefulStop` adds a 1s sleep — a fixed ~24s shutdown regardless of whether any request is truly in flight. The fix is to add `dpq.consumer.cli.doAfter(MessageHookPoints_RECEIVE, make([]*MessageCommon, 0), duration, MessageHookPointsStatus_OK)` in the `isNoNewMessage` branch. I'll prepare a fix spec and work on a PR. The community is welcome to provide feedback on the approach before implementation. --- 🤖 *Automated issue analysis 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
