Aias00 opened a new issue, #4367:
URL: https://github.com/apache/rocketmq-dashboard/issues/4367
## Problem
RocketMQ 5.x gRPC/POP consumers may appear in broker-side `ConsumeStats`
with a negative
`brokerOffset - consumerOffset`. The Studio currently routes that value
through
`ConsumerLagResolver`, but the fallback interface has no request context and
the only implementation
is `NoopProxyStatsProvider`, which always returns `UNKNOWN`.
As a result, the consumer-group list, consumer-group queue progress, and
topic-consumer list can only
report the lag as unavailable even though the already-discovered RocketMQ
Proxy remoting endpoint can
answer the authoritative offset requests.
This is distinct from:
- #4293, which fixes how an unknown lag is presented by the topic-consumer
API.
- #4361 / #4362, which distinguish failed live statistics from a real zero.
- #2504, which added Proxy consumer discovery but intentionally left lag
transport as a no-op.
## Proposed design
### Context-aware lag contract
Change `ProxyStatsProvider` so a lookup receives the selected `instanceId`,
`consumerGroup`, and the
already-known `MessageQueue`. This supplies the routing fields required by
Proxy and avoids a second
topic-route scan.
### Proxy remoting requests
Implement the contract in the existing `ProxyConsumerResolver`, reusing its
per-instance Proxy address
discovery/cache and its bounded 2-second remoting timeout.
For each discovered Proxy address, query both offsets for the same queue:
1. `GET_MAX_OFFSET` (`RequestCode` 30), with `topic`, `queueId`,
`bname`/broker name, and committed
offset semantics.
2. `QUERY_CONSUMER_OFFSET` (`RequestCode` 14), with `consumerGroup`,
`topic`, `queueId`, and
`bname`/broker name. Do not request a fabricated zero when an offset is
absent.
Decode the standard `GetMaxOffsetResponseHeader` and
`QueryConsumerOffsetResponseHeader`. Return the
non-negative difference only when both responses are successful and
complete. If a Proxy is
unreachable or returns an incomplete/non-success response, try the next
discovered Proxy; return
`ConsumerLagResolver.UNKNOWN` if none can produce a complete pair.
### Consumer paths
Pass queue context through every current `resolveDiff` call so the real
Proxy fallback is used by:
- consumer-group list enrichment;
- consumer-group queue-progress detail;
- paged topic-consumer statistics.
Known broker-side non-negative lag remains authoritative and must not
trigger Proxy requests.
## Failure semantics
- A real offset difference of zero remains `0`.
- Missing headers, non-success response codes, timeouts, unreachable
Proxies, or negative Proxy offset
differences remain `UNKNOWN` (`-1`).
- Partial data must never be summed with known queues or converted to zero.
- No new route traversal or unbounded retry loop is introduced.
## Test plan
- Protocol-vector tests for both request codes and all required
custom-header fields.
- Known positive and known-zero lag responses.
- Fallback to a later Proxy after an unreachable/non-success response.
- Null, malformed, partial, timeout, and negative-difference responses
degrade to `UNKNOWN`.
- Metadata-provider tests prove the selected instance, group, and queue are
passed in the group list,
group progress, and topic-consumer paths.
- Existing broker-known lag behavior remains unchanged and does not call
Proxy.
- Run focused provider tests, the full backend test suite with Java 21,
Checkstyle/build, and frontend
tests/build/lint because the affected values are rendered by existing UI
paths.
--
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]
