github-actions[bot] commented on code in PR #68066:
URL: https://github.com/apache/doris/pull/68066#discussion_r4044582992


##########
fe/fe-core/src/main/java/org/apache/doris/system/HeartbeatMgr.java:
##########
@@ -217,9 +218,13 @@ private boolean handleHbResponse(HeartbeatResponse 
response, boolean isReplay) {
                     } else {
                         // invalid all connections cached in ClientPool
                         ClientPool.backendPool.clearPool(new 
TNetworkAddress(be.getHost(), be.getBePort()));
-                        if (!isReplay && System.currentTimeMillis() - 
be.getLastUpdateMs()
-                                >= 
Config.abort_txn_after_lost_heartbeat_time_second * 1000L
-                                && be.getLastUpdateMs() > 0) {
+                        long lostTimeMs = System.currentTimeMillis() - 
be.getLastUpdateMs();
+                        long timeoutMs = 
Config.abort_txn_after_lost_heartbeat_time_second * 1000L;
+                        boolean nonNormalCloudCluster = Config.isCloudMode()
+                                && 
!ClusterStatus.NORMAL.name().equals(be.getCloudClusterStatus());
+                        // Bound repeated MS scans for inactive clusters to 
[timeoutMs, 2 * timeoutMs).
+                        if (!isReplay && be.getLastUpdateMs() > 0 && 
lostTimeMs >= timeoutMs
+                                && (!nonNormalCloudCluster || lostTimeMs < 2 * 
timeoutMs)) {

Review Comment:
   [P1] Guarantee one cleanup submission before expiring this window
   
   Elapsed time does not prove that this FE generation ever submitted cleanup. 
For example, this timeout is mutable and unvalidated: with `T=1s` and the 
normal 10s heartbeat cadence, the first failed heartbeat is already beyond 
`2T`, so this branch rejects it and every later failure. Failover has the same 
problem even with `T=60s`, because unchanged healthy `lastUpdateMs` values are 
journaled only every 300-359s; a promoted FE can replay an age beyond `2T` 
although the BE was just lost, and failed responses keep reusing that 
timestamp. Cloud FE's timeout cleaner is a no-op, so affected PREPARE 
transactions fall back to the much later MS timeout. Please suppress repeats 
using per-outage attempt state that is safe across promotion, or otherwise 
guarantee at least one post-threshold submission, and cover cadence/failover 
cases in the test.



-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to