apache/rocketmq · error · RemotingCommandException
Failed to get max offset in queue
Error message
Failed to get max offset in queue
What it means
In Broker2Client's reset-offset flow, when the caller passes timeStamp == -1 (meaning 'reset to latest'), the broker resolves the latest offset via messageStore.getMaxOffsetInQueue(). Since getMaxOffsetInQueue declares ConsumeQueueException (a checked store-level failure), the processor wraps it in RemotingCommandException('Failed to get max offset in queue'). The resetOffset request therefore aborts before any offset table is pushed to consumers.
Source
Thrown at broker/src/main/java/org/apache/rocketmq/broker/client/net/Broker2Client.java:153
MessageQueue mq = new MessageQueue();
mq.setBrokerName(this.brokerController.getBrokerConfig().getBrokerName());
mq.setTopic(topic);
mq.setQueueId(i);
long consumerOffset =
this.brokerController.getConsumerOffsetManager().queryOffset(group, topic, i);
if (-1 == consumerOffset) {
response.setCode(ResponseCode.SYSTEM_ERROR);
response.setRemark(String.format("THe consumer group <%s> not exist", group));
return response;
}
long timeStampOffset;
if (timeStamp == -1) {
try {
timeStampOffset = this.brokerController.getMessageStore().getMaxOffsetInQueue(topic, i);
} catch (ConsumeQueueException e) {
throw new RemotingCommandException("Failed to get max offset in queue", e);
}
} else {
timeStampOffset = this.brokerController.getMessageStore().getOffsetInQueueByTime(topic, i, timeStamp);
}
if (timeStampOffset < 0) {
log.warn("reset offset is invalid. topic={}, queueId={}, timeStampOffset={}", topic, i, timeStampOffset);
timeStampOffset = 0;
}
if (isForce || timeStampOffset < consumerOffset) {
offsetTable.put(mq, timeStampOffset);
} else {
offsetTable.put(mq, consumerOffset);
}
}
ResetOffsetRequestHeader requestHeader = new ResetOffsetRequestHeader();View on GitHub (pinned to 293f588571)
Solutions
- Check broker logs for the underlying ConsumeQueueException and the affected topic/queue
- Verify the topic and queue exist on this broker (topicRoute/queryTopic) before resetting offsets
- If consume queue files are damaged, recover or rebuild them (store recovery on restart) before retrying the reset
- Retry the admin operation when the broker store is fully healthy
Defensive patterns
Strategy: validation
Validate before calling
// before issuing resetOffset with latest semantics, confirm the queue is readable
long probe = brokerController.getMessageStore().getMinOffsetInQueue(topic, queueId);
if (probe < 0) throw new IllegalStateException("queue not available: " + topic + "-" + queueId); Try / catch
try {
adminExt.resetOffsetByTime(topic, group, timestamp);
} catch (Exception e) {
Throwable real = ExceptionUtils.getRealException(e);
if (real instanceof RemotingCommandException) { /* store-level failure: check broker logs, retry later */ }
} Prevention
- Do not reset offsets while deleting or migrating the topic
- Run admin offset resets only against a fully started, healthy broker
When it happens
Trigger: mqadmin resetOffsetByTime with no timestamp (latest) or the admin ResetOffset request with timeStamp=-1 against a topic/queue whose consume queue read fails in the store — e.g. queue files missing/corrupt or store in a failed state.
Common situations: Resetting offsets on a topic whose consume queue was manually deleted or corrupted; store shutdown in progress during the admin call; deleting a topic concurrently with resetOffset.
Related errors
- Failed to get max offset in queue
- Failed to get max offset
- Failed to get max offset in queue
- Failed to ack message
- Failed to get max offset
AI-assisted analysis of apache/rocketmq@293f588571 (2026-08-14).
Data as JSON: /api/errors/928887c88b1ed752.
Report an issue: GitHub.