unbridled-41 commented on PR #11048:
URL: https://github.com/apache/rocketmq/pull/11048#issuecomment-5970066958
Re-armed completion in 507763ba1.
`TimerRequest.rearmLatch(latch)` sets the new latch and clears `released`,
and the retry loop uses it instead of `setLatch`. The javadoc records your
dequeue-handoff caveat: a request still owned by the dequeue pipeline may
complete the new latch early, which is benign here because the loop drives
progress from `isSucc()` rather than the latch — a late release that sets
`succ=true` also makes the request ineligible for the next round, and an early
countdown at worst skips part of the completion wait.
**The test now asserts the retry latch reaches zero.** The regression test
overrides `checkDequeueLatch` to record each round's latch, so the production
wait can no longer mask an incomplete round:
```java
assertEquals("the retry round must complete its latch", 0,
roundLatches.get(1).getCount());
```
Before the change: `java.lang.AssertionError: the retry round must complete
its latch expected:<0> but was:<1>` — in production this is the `Check latch
failed delayedTime:-1` warning plus the timeout on every successful retry.
After: the test passes, and the existing assertions still pin that the
already-succeeded request is not re-enqueued.
--
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]
