luoyuxia commented on code in PR #2265:
URL: https://github.com/apache/fluss/pull/2265#discussion_r2678345449
##########
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:
@rionmonster
> Later, a stale duplicate entry for T ends up in the pending queue (e.g.,
due to retries, late timer callbacks, or test churn).
As for the fail test, which case cause a stale duplicate T entering into
pending queue? Do you have ever find any logs?
> would poll T from the pending queue and attempt to assign it again, even
though its actual state was no longer Pending
If it's a invalid state changte, we'll print
```
Fail to change state for table xxx
```
But I can't see such log in the fail ci
> but the table was still returned to the tiering service, causing things to
become inconsistent between the pendingTieringTables and tieringStates.
To me, it looks me like that the table won't be returned to the tiering
service anymore from the log.
So, i'm a little doubt about this case.
Could you please share me your reproduce branch, I want reproduce it in my
local env to find the root cause.
--
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]
