rionmonster commented on code in PR #2265:
URL: https://github.com/apache/fluss/pull/2265#discussion_r2678318537
##########
fluss-lake/fluss-lake-iceberg/src/test/java/org/apache/fluss/lake/iceberg/maintenance/IcebergRewriteITCase.java:
##########
@@ -186,6 +186,9 @@ void testLogTableCompaction() throws Exception {
t1, t1Bucket, ++i, true,
Collections.singletonList(row(1, "v1"))));
checkFileStatusInIcebergTable(t1, 3, false);
+ // Ensure tiering job has fully processed the previous writes
+ assertReplicaStatus(t1Bucket, i);
Review Comment:
@luoyuxia
Sure! Cleaning up some of my notes from the troubleshooting session, but
hopefully this workflow makes sense:
1. A table `T` becomes eligible and is assigned normally (Pending to
Tiering).
2. Later, a stale duplicate entry for `T` ends up in the pending queue
(e.g., due to retries, late timer callbacks, or test churn).
3. Before the fix, `requestTable()` would poll `T` from the pending queue
and attempt to assign it again, even though its actual state was no longer
Pending.
4. That resulted in an invalid state transition attempt (non-Pending/Tiering
to Tiering), but the table was still returned to the tiering service, causing
things to become inconsistent between the `pendingTieringTables` and
`tieringStates`.
The key difference with this change is that after it `requestTable()`
actually verifies the table is in the Pending state before assigning it instead
of just relying on its presence in the pending queue.
--
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]
