guyinyou opened a new pull request, #1378: URL: https://github.com/apache/rocketmq-clients/pull/1378
### Which Issue(s) This PR Fixes No existing issue. Found while running a long-lived push consumer against a real RocketMQ 5.0 instance: shutdown logged ``` WARN push_consumer.go Timeout waiting for all inflight receive requests to be finished, inflightReceiveRequestCount=1616 ``` after 33 minutes on a topic with little traffic. Independent of #1377 (no overlapping files). ### Brief Description `receiveMessageImmediatelyWithAttemptId` opens the `RECEIVE` hook with `doBefore` before every long polling request, and the goroutine that completes the request closes it with `doAfter`. The branch handling `MESSAGE_NOT_FOUND` — the normal answer for a queue with no traffic — only wrote a debug log, so every empty poll leaked one inflight reception. The counter is only ever incremented on this path, so it never came back down. The consequence is shutdown latency: `waitingReceiveRequestFinished` polls until the count reaches zero, which it never does, so every `GracefulStop` on a push consumer with an idle topic burns its full `requestTimeout + longPollingTimeout` (about 33s with the defaults) before logging the timeout above and continuing. The fix reports the completed reception on every error path, so the hook pairing is balanced by construction: - `MessageHookPointsStatus_OK` for an empty poll — it is a reception that completed and found nothing, which matches the existing debug-only treatment; - `MessageHookPointsStatus_ERROR` for a real failure, with the existing error log unchanged. Metrics are unaffected: `doAfterReceiveMessage` returns early when the message list is empty, and the failure branch already called `doAfter` with an empty list, so idle polling still records nothing. ### How Did You Test This Change? Verified locally on **macOS arm64**, Go 1.24.2: - [x] New regression test `TestProcessQueueEmptyLongPollingBalancesInflightReceiveCount`: registers a process queue through the production `createProcessQueue` path, answers every long polling receive with a `MESSAGE_NOT_FOUND` status followed by `EOF` the way an idle queue does, and asserts the inflight count returns to zero once at least five receptions have completed. **Before this change it fails with `inflight receive count is 5 after 5 completed receptions`; after it, it passes in 0.08s.** - [x] `go build ./...`, `gofmt`, and the full `go test -count=1 ./...`: ok (13.2s). - [x] `codespell` 2.1.0 with the arguments from `.github/workflows/codespell_check.yaml`. - [x] `go test -race`: the six failing tests on this branch are exactly the six that fail on pristine `master` at the merge base — `TestCMClearIdleRpcClients`, `Test_execute_server_telemetry_command`, `Test_execute_server_telemetry_command_fail`, `TestRestoreDefaultClientSessionZeroErrors`, `TestRestoreDefaultClientSessionOneError`, `TestRestoreDefaultClientSessionTwoErrors` — verified by running the same command in a separate worktree checked out at `master`. This change adds none of them; they are pre-existing and are addressed in #1377. - [x] `go vet ./...`: 13 pre-existing `lostcancel` warnings on `master`, unchanged by this PR. -- 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]
