danny0405 commented on issue #19360:
URL: https://github.com/apache/hudi/issues/19360#issuecomment-5089965098
Yes — with one important qualification: “server ahead” should mean that the
server timeline is an exact extension of the client timeline, not merely that
the server has a greater latest instant timestamp.
Comparing
```java
localTimeline.findInstantsBeforeOrEquals(lastKnownInstantFromClient)
.getTimelineHash()
```
with the client hash provides that proof. If they match, the server contains
exactly the client timeline through the client boundary, and the remaining
server instants are newer additions. Reloading cannot add anything required by
that client request.
This is safer than the latest-instant/count heuristic reverted by #6179,
because the hash includes every instant requested time, action, and state. For
example, if an earlier inflight instant completes after a later clean instant,
the server prefix changes and the hashes do not match, so the refresh is
retained.
So the intended decision would be:
- full hashes equal: no refresh;
- hashes differ, but the server prefix hash equals the client hash: the
server is a proven extension, so no refresh;
- prefix hash differs: the timelines diverge at or before the client
boundary, so refresh conservatively.
I do not see a correctness case where the prefix hashes match yet a reload
is required, assuming both sides use the same timeline filtering and hashing
rules. A later server `lastInstant` alone is not sufficient to establish that
the server is ahead.
There can still be conservative false positives. For example, timeline
archival may remove old client instants from the server active timeline, and an
out-of-order completion at or before the client boundary can make the prefix
differ even if the server is effectively newer. Those cases may still reload
unnecessarily, but they remain correctness-safe; eliminating them would require
richer protocol information than a single full hash and boundary timestamp.
--
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]
