[GitHub] [flink] XComp commented on pull request #21537: [FLINK-30462][runtime] The leader session ID is now saved properly

[GitBox <gi...@apache.org>]

XComp commented on PR #21537:
URL: https://github.com/apache/flink/pull/21537#issuecomment-1360981811

   > It might be worth considering guarding against multiple calls to isLeader, by checking the currentLeaderSession is null.
   
   The [LeaderLatchListener](https://github.com/apache/curator/blob/master/curator-recipes/src/main/java/org/apache/curator/framework/recipes/leader/LeaderLatchListener.java) interface provided by curator is clear on that here. But I couldn't find anything about a clear/consistent order of calls for the fabric8 k8s client in its docs (e.g. in [LeaderCallbacks](https://github.com/fabric8io/kubernetes-client/blob/master/kubernetes-client-api/src/main/java/io/fabric8/kubernetes/client/extended/leaderelection/LeaderCallbacks.java)) or the tests (e.g. [LeaderElectorTest](https://github.com/fabric8io/kubernetes-client/blob/master/kubernetes-client-api/src/test/java/io/fabric8/kubernetes/client/extended/leaderelection/LeaderElectorTest.java)). The code in [LeaderElector:71-73](https://github.com/fabric8io/kubernetes-client/blob/v5.12.3/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/extended/leaderelection/LeaderElector.java#L71-L73) for the fabric8's k8s client version we use 
 (5.12.3) suggests that, though. Initially, I wasn't comfortable considering adding that precondition with the fabric8 k8s client not documenting a clear ordering anywhere. But probably one can argue that it's a common contract of leader election that the `isLeader` and `isNoLeader` are consistently pushed to the client(s).


-- 
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: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org