nsivabalan commented on code in PR #13064:
URL: https://github.com/apache/hudi/pull/13064#discussion_r2025894932
##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/table/action/rollback/BaseRollbackPlanActionExecutor.java:
##########
@@ -129,9 +138,36 @@ protected Option<HoodieRollbackPlan>
requestRollback(String startRollbackTime) {
}
}
+ private boolean canProceedWithRollback(HoodieInstant rollbackInstant) {
+ if
(config.getWriteConcurrencyMode().supportsOptimisticConcurrencyControl()) {
+ // check for concurrent rollbacks. i.e if the commit being rolledback is
already rolled back, we can bail out.
+ HoodieTableMetaClient reloadedMetaClient =
HoodieTableMetaClient.reload(table.getMetaClient());
Review Comment:
actually the reason is 2 call stacks down.
in L 152 we call
validateForLatestTimestampWithoutReload() w/ reloaded meta client as
argument.
eventually this calls into
TimestampUtils.validateForLatestTimestamp
within this method, we might need to reload the timeline in most cases. Only
in case of this rollback flow, we do not need to reload the timeline.
but to reload the timeline, we need an instant of "HoodieTableMetaClient"
and so we could do metaClient.reloadActiveTimeline().
In other words, we can't just take in an activeTimeline as an argument to
TimestampUtils.validateForLatestTimestamp
I did think about adding two Optional arguments to this method. but felt it
may not be elegant.
--
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: commits-unsubscr...@hudi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
