You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by GitBox <gi...@apache.org> on 2026/07/28 09:08:32 UTC
[GH] (rocketmq/fix/pop-revive-future-exceptionally): Workflow run "Build and Run Tests by Maven" failed!
The GitHub Actions job "Build and Run Tests by Maven" on rocketmq.git/fix/pop-revive-future-exceptionally has failed.
Run started by GitHub user wang-jiahua (triggered by wang-jiahua).
Head commit for run:
b84fcc0a3c37744e9ae5c9368b21e497072f83f1 / wangjiahua.wjh <wa...@alibaba-inc.com>
[ISSUE #10658] Attach the exception-to-false conversion at the batch call site only
Address the review on #10659: revive(PopConsumerRecord) is also used as the
Consumer<PopConsumerRecord> callback of PopConsumerCache (enablePopBufferMerge),
where the returned future is discarded, so a false result would never be consumed
there. Converting exceptions to false inside revive(record) therefore created a
contract that one caller silently ignores, and the "will retry" log would be
misleading on that path.
Move the .exceptionally handler out of revive(record) to the batch call site in
revive(AtomicLong, int), where a false result is actually consumed and turned into
a failureList backoff retry. revive(record) keeps its original exception semantics,
so the PopConsumerCache path behaves exactly as it did before this PR. The
pre-existing issue that an asynchronously failed revive can be cleared from the
cache without being persisted for retry is tracked separately.
Both regression tests still pass:
reviveShouldNotAbortBatchWhenGetMessageFailsExceptionally and
reviveShouldIsolateSynchronousReadFailureAndNotBlockHealthyRecords.
Report URL: https://github.com/apache/rocketmq/actions/runs/30340943627
With regards,
GitHub Actions via GitBox