Beutlin commented on code in PR #18123:
URL: https://github.com/apache/iceberg/pull/18123#discussion_r4146741538
##########
flink/v2.3/flink/src/main/java/org/apache/iceberg/flink/sink/IcebergCommitter.java:
##########
@@ -138,13 +141,24 @@ public void
commit(Collection<CommitRequest<IcebergCommittable>> commitRequests)
}
IcebergCommittable last =
commitRequestMap.lastEntry().getValue().getCommittable();
+ // A stateless start has no committed checkpoints; the table's mark would
drop every commit.
long maxCommittedCheckpointId =
- SinkUtil.getMaxCommittedCheckpointId(table, last.jobId(),
last.operatorId(), branch);
+ isRestored
+ ? SinkUtil.getMaxCommittedCheckpointId(table, last.jobId(),
last.operatorId(), branch)
+ : SinkUtil.INITIAL_CHECKPOINT_ID;
Review Comment:
This isn't new behavior though — the legacy IcebergFilesCommitter (Sink V1)
has used the same isRestored gate for years (see IcebergFilesCommitter.java
lines 166/170/191): no restore means no lookup, same as here. So this would
already apply to any V1 batch user today.
More fundamentally, I don't think any variant avoids both failure modes at
once: from jobId + checkpoint id alone, we can't distinguish a stale marker
from an unrelated stateless restart (→ #18098, ignore it) from a real marker
after a rollback to an earlier checkpoint (→ your case, must respect it).
Resetting fixes one and breaks the other; clamping just shrinks the second
problem instead of closing it.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
