binary-signal commented on issue #3483:
URL: https://github.com/apache/fluss/issues/3483#issuecomment-4762396514
Thanks @luoyuxia, your reading is correct, and digging further into it
confirmed your instinct about case (2).
@Jackeyzhe Sounds good to me, scoping this PR to case (1) is the right call.
The race in case (1) is confirmed and reproducible; case (2) only shows up
through a narrow timing window, so it shouldn't block this.
One clarification on the "old lake snapshot still visible after drop +
recreate" point, since it's the part that feels uncertain: it isn't really
conditional. Fluss never drops the lake table on dropTable (the LakeCatalog API
has no dropTable), so the Paimon table and its snapshot carrying the t-<oldId>
offsets property always survive. And getMissingLakeSnapshot keys on table path
+ commit user, not tableId, so a new incarnation can read it. The only
genuinely race-dependent part is the lake table being empty at the time of
recreate (so checkTableIsEmpty passes) and the old in-flight commit landing
just after.
So +1 on case (2) as a follow-up. The defensive validation that fits is
checking the -<id> segment of the offsets path against the commit's tableId in
the recovery path, which closes it regardless of timing.
Thanks for picking this up!
--
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]
