fix: fix null point and some typo errors

[enkilee]

Which Issue(s) This PR Fixes

• Fixes #issue_id

Brief Description

fix null point and some typo errors:
null point1:
ChangeInvisibleTimeProcessor.java:340-347

if (putMessageResult != null) {                       // line 340: 判空
    brokerController...incPopReviveCkPutCount(...);
    if (putMessageResult.isOk()) { ... }
}
if (putMessageResult.getPutMessageStatus() != ...) {  // line 347: 在 if 块外，未判空 → NPE

null point2:
ExpressionForRetryMessageFilter.java:61-65

if (tempProperties == null && msgBuffer != null) {    // line 61
    decoded = true;
    tempProperties = MessageDecoder.decodeProperties(msgBuffer);
}
String realTopic = tempProperties.get(...);            // line 65: 当 tempProperties==null && msgBuffer==null 时 NPE

typo errors:
bakeup -> backup

How Did You Test This Change?

[RockteMQ-AI]

Review by github-manager-bot

Thanks for the PR @enkilee. Here is my analysis of the changes:

1. ChangeInvisibleTimeProcessor.java — NPE fix ✅

Moving the putMessageStatus check inside the putMessageResult != null guard correctly prevents the NPE. The logic restructuring is sound.

Note: When putMessageResult == null, the original code would fall through to ackOrigin() in the outer else branch. The new code returns CompletableFuture.completedFuture(false) instead. This is a behavioral change — previously a null put result would still attempt to ack origin, now it returns failure. This seems safer (checkpoint write failed → do not proceed), but worth confirming this is the intended behavior.

2. ExpressionForRetryMessageFilter.java — NPE fix ⚠️

The null guard on tempProperties prevents the NPE, but returning true (i.e., treating the message as matched) when properties cannot be decoded is a fail-open approach. This means undecodable messages will pass through the filter unconditionally.

Consider whether this is the desired semantics:

• If the intent is "cannot determine → let it through" (fail-open), this is correct but a comment explaining the rationale would help future maintainers.
• If the intent is "cannot determine → reject" (fail-close), the return should be false.

3. TopicQueueMappingManager.java — Typo fix ✅

bakeup → backup — straightforward and correct.

---

Summary: The NPE fixes are valid. The main points to verify are (1) the behavioral change in ChangeInvisibleTimeProcessor when putMessageResult is null, and (2) the fail-open semantics in ExpressionForRetryMessageFilter.

[RockteMQ-AI]

Review by github-manager-bot (Re-review)

Thanks for the update @enkilee. The new commit addresses the concern raised in the previous review.

Changes since last review

ExpressionForRetryMessageFilter.java — Switched from fail-open to fail-close ✅

The previous review noted that returning true when properties cannot be decoded was a fail-open approach. The new code now returns false (fail-close), which is the safer semantic — undecodable messages will be filtered out rather than unconditionally passing through. This is the correct choice.

Unchanged from previous review (still valid)

1. ChangeInvisibleTimeProcessor.java — NPE fix ✅ — The behavioral change (returning false when putMessageResult is null) remains sound and safer than the original.
2. TopicQueueMappingManager.java — Typo fix bakeup → backup ✅

Summary

The PR looks good. The fail-close approach in ExpressionForRetryMessageFilter is the right call. LGTM.

---

Automated re-review by github-manager-bot