The GitHub Actions job "CI" on rocketmq-dashboard.git/fix/btl-inst-count-cancel has succeeded. Run started by GitHub user btlqql (triggered by btlqql).
Head commit for run: e10af3177aed72b83617d117d86987c2144f1284 / btlqql <[email protected]> fix(instance): stop a cancelled count batch before the second lookup (#7077) InstanceService.loadCounts started countGroups unconditionally after countTopics. A batch that had already reached its deadline or been cancelled interrupts its worker, but a provider that ignores the interrupt can still return the first count afterwards, so the worker went on to start the second provider lookup for a response nobody was waiting for. loadCounts now checks the worker interrupt flag between the two lookups and throws InterruptedException when it is still set. The exception takes the runner's existing failure path (InstanceResourceCountRunner.execute -> CompletedCount.failure), so there is no executor policy change: the caller keeps its existing unavailable response and a healthy batch still performs both lookups. Thread.interrupted() consumes the flag the way any InterruptedException producer does, so the pooled worker does not inherit a stale interrupt for its next count task. Because that exception surfaces as a failed outcome, fillCountsInParallel now treats an InterruptedException as a cancellation rather than a provider failure: the instance still loses its counts, but the event is logged at debug instead of counting as a failed lookup. A cancelled batch is routine, and counting it as a failure would have made the failure signal meaningless. The pre-existing late-result test signalled its "provider finished" latch from countGroups and thus required the unwanted lookup; it now signals that latch when the first lookup returns. Report URL: https://github.com/apache/rocketmq-dashboard/actions/runs/39289656784 With regards, GitHub Actions via GitBox
