luoyuxia commented on PR #3494: URL: https://github.com/apache/fluss/pull/3494#issuecomment-4881420963
@Jackeyzhe Thanks for working on this. I wonder if we can make this fix simpler and close the race at the ZK write boundary instead. The current approach adds coordinator-side lifecycle checks before submitting the actual ZK write to `ioExecutor`, but that check can become stale before `registerLakeTableSnapshotV2` runs. For example, the commit event may pass the context check while the table still exists, then `dropTable` can delete `/tabletservers/tables/<tableId>`, and the later IO task can still recreate `/tabletservers/tables/<tableId>/laketable` because `upsertLakeTable` uses `creatingParentsIfNeeded()`. Would it be enough to change the create branch in `ZooKeeperClient.upsertLakeTable` to avoid recreating the table parent? ```java // Do not recreate /tabletservers/tables/<tableId> for a late commit. zkClient.create().forPath(zkPath, zkData); ``` Then a late commit after `deleteTableAssignment(tableId)` would fail with `NoNodeException` instead of resurrecting the old tableId znode. We can convert that to `TableNotExistException` for the commit response. The coordinator-side queued/deleted check can still be kept as an early rejection, but the ZK write itself should be what prevents the resurrection race. -- 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]
