binarybrain-009 commented on code in PR #18494:
URL: https://github.com/apache/iceberg/pull/18494#discussion_r4401621646


##########
spark/v4.1/spark/src/main/java/org/apache/iceberg/spark/source/SyncSparkMicroBatchPlanner.java:
##########
@@ -234,6 +245,36 @@ public StreamingOffset latestOffset(StreamingOffset 
startOffset, ReadLimit limit
     return latestStreamingOffset.equals(startingOffset) ? null : 
latestStreamingOffset;
   }
 
+  // Computes latestOffset for an unbounded (allAvailable) limit without 
per-file planning: the end
+  // offset is the latest valid snapshot's added-file count (or the 
pre-computed
+  // Trigger.AvailableNow
+  // cap), reached by walking only the snapshot chain. See latestOffset for 
the rationale.
+  private StreamingOffset latestOffsetForUnbounded(
+      StreamingOffset startingOffset, Snapshot curSnapshot) {
+    StreamingOffset latestStreamingOffset;
+    if (lastOffsetForTriggerAvailableNow != null) {
+      // Trigger.AvailableNow caps the run at a snapshot computed up front.
+      latestStreamingOffset = lastOffsetForTriggerAvailableNow;
+    } else {
+      // Advance the snapshot chain (metadata only) to the latest valid 
snapshot.
+      Snapshot lastValidSnapshot = curSnapshot;
+      Snapshot next;
+      do {
+        next = nextValidSnapshot(lastValidSnapshot);
+        if (next != null) {
+          lastValidSnapshot = next;
+        }
+      } while (next != null);
+      latestStreamingOffset =
+          new StreamingOffset(
+              lastValidSnapshot.snapshotId(),
+              MicroBatchUtils.addedFilesCount(table(), lastValidSnapshot),

Review Comment:
   Good catch, thanks! It doesn't: a merged manifest's existing entries take 
positions too, so the file after it was skipped. The short-circuit now ends at 
the start of the snapshot's last manifest plus that manifest's added files, 
which is where the full loop ends, and the Trigger.AvailableNow cap gets the 
same position instead of being returned as is. Added 
`latestOffsetForUnboundedLimitIncludesFilesAfterMergedManifest`, which fails 
without the change.
   
   The async planner makes the same assumption (its unbounded `latestOffset` 
and the positions it queues), and with this layout its `planFiles` keeps 
waiting for an end offset that never arrives, so the test runs only for the 
sync planner. `planFiles` also uses `addedFilesCount` as the end of 
intermediate snapshots. Both predate this PR, so I'd rather fix them in a 
follow-up if that works for you.
   



-- 
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]

Reply via email to