swuferhong commented on code in PR #3400:
URL: https://github.com/apache/fluss/pull/3400#discussion_r3345545972
##########
fluss-server/src/main/java/org/apache/fluss/server/coordinator/CoordinatorRequestBatch.java:
##########
@@ -422,12 +433,20 @@ private void sendNotifyLeaderAndIsrRequest(int
coordinatorEpoch) {
"Failed to send notify leader and isr
request to tablet server {}.",
serverId,
throwable);
- // todo: in FLUSS-55886145, we will introduce a
sender thread to send
- // the request, and retry if encounter any error;
It may happens that
- // the tablet server is offline and will always
got error. But,
- // coordinator will remove the sender for the
tablet server and mark all
- // replica in the tablet server as offline. so, in
here, if encounter
- // any error, we just ignore it.
+ // Treat all buckets as failed — clears pending
state and triggers
+ // re-election via onReplicaBecomeOffline.
+ List<NotifyLeaderAndIsrResultForBucket>
failedResults =
+ new ArrayList<>();
+ ApiError sendError =
Review Comment:
Good catch. I have reverted it — the original "just ignore" approach was
intentional (the coordinator detects actual server death via heartbeat
timeout). The only thing I kept is clearing the pendingLeaderActivationBuckets
on send failure, so the health API doesn't report stale `RED` for buckets that
are simply stuck in the pending set. Actual failover is still handled by the
existing heartbeat/offline mechanism.
--
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]