[Bug] Tiered store dispatch metrics silently ignore ConsumeQueueException

Open Beginner friendly
#11,166 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
1/5
Estimated time
1-3 hours
Newbie friendliness
88/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java
Domain
observability

Research direction

Start in TieredStoreMetricsManager.initMetrics() and inspect the two existing ConsumeQueueException catch blocks for the dispatchBehind and dispatchLatency gauges. Compare their handling with the gauge callbacks in PopMetricsManager, then verify that both failures log exception details while normal metric collection and message processing remain unchanged.

Written by the indexing model from the issue text.

Description

Describe the Bug

TieredStoreMetricsManager catches ConsumeQueueException while collecting the dispatchBehind and dispatchLatency gauges, then silently ignores the exception. The affected callbacks are in initMetrics().

When either collection path fails, the metric has no measurement for that collection cycle and the broker logs do not show the failure. Operators cannot distinguish a zero metric value from an unsuccessful collection attempt.

PopMetricsManager logs ConsumeQueueException with log.error(message, e) for its gauge callbacks. Applying the same handling here keeps the metric callbacks non-disruptive while making failures observable.

Expected Behavior

Tiered Store metric collection failures should be logged with the exception details.

Additional Context

The proposed change only adds error logging in the two existing catch (ConsumeQueueException e) blocks. Normal metric collection and message processing behavior remain unchanged.

Dominant language
Java
Stars
22.6k
Forks
12k
Avg merge
3d 12h
Merged PRs (30d)
25

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/rocketmq

All issues in apache/rocketmq

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.