alanlau28 commented on code in PR #23298:
URL: https://github.com/apache/kafka/pull/23298#discussion_r3972814271


##########
streams/src/main/java/org/apache/kafka/streams/processor/internals/ProcessorStateManager.java:
##########
@@ -92,13 +92,15 @@ public static class StateStoreMetadata {
         // applied to the store used for both restoration (active and standby 
tasks restored offset) and
         // normal processing that update stores (written offset); could be 
null (when initialized)
         //
-        // the offset is updated in three ways:
+        // the offset is updated in four ways:
         //   1. when loading from the checkpoint file, when the corresponding 
task has acquired the state
         //      directory lock and have registered all the state store; it is 
only one-time
         //   2. when updating with restore records (by both restoring active 
and standby),
         //      update to the last restore record's offset
         //   3. when checkpointing with the given written offsets from record 
collector,
         //      update blindly with the given offset
+        //   4. when restoration reaches a confirmed catch-up boundary with no 
further records to apply
+        //      (KAFKA-14302), as last-applied = next-fetch - 1, never moving 
backwards

Review Comment:
   Maybe this can be worded to match the "when X, update to Y" shape of items 
1–3, and to note that standbys reach the *limit* offset, not the end offset?
   
   (also dropping the repeated `KAFKA-14302` here — kept once on the 
`advanceRestoredOffsetTo` Javadoc.)
   
   ```suggestion
           //   4. when restoration reaches the end offset (the limit offset 
for standbys) with no further
           //      records to apply, update to next-fetch minus one 
(last-applied); never moves backwards
   ```



##########
streams/src/main/java/org/apache/kafka/streams/processor/internals/StoreChangelogReader.java:
##########
@@ -749,6 +749,10 @@ private int restoreChangelog(final Task task, final 
ChangelogMetadata changelogM
             // markers) so the remaining-records metric reaches exactly zero 
on completion
             recordRestorationProgress(task, changelogMetadata, 0, 
storeMetadata.offset(), changelogMetadata.restoreEndOffset);
 
+            // Catch-up boundary: advertise restoreEndOffset, not the live 
consumer position, which may
+            // already be past records that were buffered and never applied 
(KAFKA-14302).

Review Comment:
   Maybe this can be worded with the file's own `end offset` term ("catch-up 
boundary" isn't used elsewhere) and `record` over `advertise`?
   
   (also dropping the repeated `KAFKA-14302` here — kept once on the 
`advanceRestoredOffsetTo` Javadoc.)
   
   ```suggestion
               // restoration reached the end offset: record restoreEndOffset, 
not the consumer position,
               // which may already be past buffered records that were never 
applied
   ```



##########
streams/src/main/java/org/apache/kafka/streams/processor/internals/StoreChangelogReader.java:
##########
@@ -769,6 +775,41 @@ private int restoreChangelog(final Task task, final 
ChangelogMetadata changelogM
         return numRecords;
     }
 
+    /**
+     * Advance a standby store's restored offset only at a confirmed catch-up 
boundary (KAFKA-14302).
+     * A zero-record poll is not sufficient: retention seeks, source-changelog 
buffering, and incomplete
+     * fetches can all leave the consumer at a non-zero position while records 
remain to apply.
+     */

Review Comment:
   Maybe this can be worded in terms of the end/limit offset rather than 
"catch-up boundary" (not a term used elsewhere in the file)?
   
   (also dropping the repeated `KAFKA-14302` here — kept once on the 
`advanceRestoredOffsetTo` Javadoc.)
   
   ```suggestion
       /**
        * Advance a standby store's restored offset only once restoration has 
actually reached the end
        * offset — the limit offset for changelogs piggy-backed on a source 
topic. A zero-record poll is
        * not sufficient: retention seeks, source buffering, and incomplete 
fetches can leave the consumer
        * at a non-zero position while records remain to apply.
        */
   ```



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

Reply via email to