[ISSUE #C1] Throw MQClientException instead of NPE for an unparseable consumeTimestamp - #11104
Open
zjncs wants to merge 1 commit into
Open
[ISSUE #C1] Throw MQClientException instead of NPE for an unparseable consumeTimestamp#11104zjncs wants to merge 1 commit into
zjncs wants to merge 1 commit into
Conversation
… consumeTimestamp computePullFromWhereWithException of both the lite pull and the push consumer chain UtilAll.parseDate(consumeTimestamp).getTime(), but parseDate returns null when the user-configured timestamp does not match the yyyyMMddHHmmss pattern. The rebalance then dies with an NPE instead of a proper error. Null-check the parsed date and throw MQClientException so the existing callers (updateProcessQueueTable and the deprecated computePullFromWhere wrapper) handle it like every other lookup failure. Signed-off-by: zjncs <18910855655@163.com>
RockteMQ-AI
approved these changes
Sep 9, 2026
RockteMQ-AI
left a comment
Contributor
There was a problem hiding this comment.
Summary
Good defensive fix — replaces an opaque NPE from UtilAll.parseDate returning null with a clear MQClientException("Invalid consumeTimestamp: ..."). Applied consistently to both RebalanceLitePullImpl and RebalancePushImpl. All callers already handle MQClientException properly, so the error message now surfaces cleanly instead of being wrapped in an NPE stack trace. Tests cover both impls.
Automated review by github-manager
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
computePullFromWhereWithExceptionin bothRebalanceLitePullImplandRebalancePushImpldoes:UtilAll.parseDatereturnsnullwhen the string does not match the pattern, andconsumeTimestampis a plain user-settable string onDefaultLitePullConsumer/DefaultMQPushConsumer. A typo likesetConsumeTimestamp("20240101")therefore kills the rebalance with an NPE (Cannot invoke Date.getTime() ... is null) instead of a proper error: the NPE escapesupdateProcessQueueTable'scatch (Exception e)... actually it is caught there (compute offset failed), but it surfaces as an opaque NPE in the logs, and the deprecatedcomputePullFromWherewrapper only handlesMQClientException, so the NPE propagates to its callers as well.Modifications
MQClientException("Invalid consumeTimestamp: ...")when it does not parse. All callers already handleMQClientException(updateProcessQueueTablecatches it and skips the queue; the deprecated wrapper logs and returns -1), so a misconfigured timestamp now produces a clear error message instead of an NPE.Verification
Fail-before (both new tests on unpatched code):
Pass-after — both test classes (existing + new tests):