You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@fluss.apache.org by "platinumhamburg (via GitHub)" <gi...@apache.org> on 2026/04/10 01:15:08 UTC
[PR] Fix stale fetch detection across poll boundaries [fluss]
platinumhamburg opened a new pull request, #3053:
URL: https://github.com/apache/fluss/pull/3053
Use nextFetchOffset for collector stale checks so a single CompletedFetch can be consumed across multiple polls without being drained as obsolete. Add focused unit and filter IT regression tests proving the pre-fix failure and post-fix correctness in single- and multi-bucket scenarios.
<!--
*Thank you very much for contributing to Fluss - we are happy that you want to help us improve Fluss. To help the community review your contribution in the best possible way, please go through the checklist below, which will get the contribution into a shape in which it can be best reviewed.*
## Contribution Checklist
- Make sure that the pull request corresponds to a [GitHub issue](https://github.com/apache/fluss/issues). Exceptions are made for typos in JavaDoc or documentation files, which need no issue.
- Name the pull request in the format "[component] Title of the pull request", where *[component]* should be replaced by the name of the component being changed. Typically, this corresponds to the component label assigned to the issue (e.g., [kv], [log], [client], [flink]). Skip *[component]* if you are unsure about which is the best component.
- Fill out the template below to describe the changes contributed by the pull request. That will give reviewers the context they need to do the review.
- Make sure that the change passes the automated tests, i.e., `mvn clean verify` passes.
- Each pull request should address only one issue, not mix up code from multiple issues.
- **Generative AI disclosure:** Indicate whether generative AI tools were used in authoring this PR. If yes, specify the tool below.
- [ ] No generative AI tools used
- [ ] Yes (please specify the tool below)
**(The sections below can be removed for hotfixes or typos)**
-->
<!--
Generated-by: [Tool Name and Version] following [the guidelines](https://github.com/apache/fluss/blob/main/AGENTS.md)
-->
### Purpose
<!-- Linking this pull request to the issue -->
Linked issue: close #3052
<!-- What is the purpose of the change -->
### Brief change log
<!-- Please describe the changes made in this pull request and explain how they address the issue -->
### Tests
<!-- List UT and IT cases to verify this change -->
### API and Format
<!-- Does this change affect API or storage format -->
### Documentation
<!-- Does this change introduce a new feature -->
--
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: issues-unsubscribe@fluss.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Fix stale fetch detection across poll boundaries [fluss]
Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #3053:
URL: https://github.com/apache/fluss/pull/3053#discussion_r3068956555
##########
fluss-client/src/main/java/org/apache/fluss/client/table/scanner/log/LogFetchCollector.java:
##########
@@ -183,7 +180,7 @@ private List<ScanRecord> fetchRecords(CompletedFetch nextInLineFetch, int maxRec
LOG.warn(
"Ignoring fetched records for {} at offset {} since the current offset is {}",
nextInLineFetch.tableBucket,
Review Comment:
The warning message here says "at offset {}" but logs `nextFetchOffset()`, which may differ from the original request offset (`fetchOffset()`) after partial consumption. This can be misleading when diagnosing truly stale fetches (you lose the original fetch start offset). Consider logging both values or switching this placeholder back to `fetchOffset()` and updating the wording accordingly.
##########
fluss-client/src/test/java/org/apache/fluss/client/table/scanner/log/LogFetcherFilterITCase.java:
##########
@@ -307,6 +309,139 @@ void testConsecutiveFetchesWithFilteredOffsetAdvancement() throws Exception {
assertThat(logFetcher.getCompletedFetchesSize()).isEqualTo(0);
}
+ @Test
+ void testFilterFetchKeepsConsumingSameCompletedFetchAcrossPolls() throws Exception {
+ // Recreate fetcher with tiny max poll records so one CompletedFetch must span polls.
+ clientConf.setInt(ConfigOptions.CLIENT_SCANNER_LOG_MAX_POLL_RECORDS, 2);
+ logFetcher.close();
+ logFetcher =
+ createFetcherWithBuckets(
+ Collections.singletonMap(new TableBucket(tableId, BUCKET_ID_0), 0L));
+
+ TableBucket tb0 = new TableBucket(tableId, BUCKET_ID_0);
+ List<Object[]> manyMatchingRows =
+ Arrays.asList(
+ new Object[] {6, "u0"},
+ new Object[] {7, "u1"},
+ new Object[] {8, "u2"},
+ new Object[] {9, "u3"},
+ new Object[] {10, "u4"},
+ new Object[] {11, "u5"});
+ addRecordsToBucket(
+ tb0,
+ LogRecordBatchStatisticsTestUtils.createLogRecordsWithStatistics(
+ manyMatchingRows, FILTER_TEST_ROW_TYPE, 0L, DEFAULT_SCHEMA_ID));
+
+ logFetcher.sendFetches();
+ retry(Duration.ofMinutes(1), () -> assertThat(logFetcher.hasAvailableFetches()).isTrue());
+
+ ScanRecords firstPoll = logFetcher.collectFetch();
+ List<ScanRecord> firstRecords = firstPoll.records(tb0);
+ assertThat(firstRecords).hasSize(2);
+ assertThat(
+ firstRecords.stream()
+ .map(r -> r.getRow().getInt(0))
+ .collect(Collectors.toList()))
+ .containsExactly(6, 7);
+ assertThat(logFetcher.getLogScannerStatus().getBucketOffset(tb0)).isEqualTo(2L);
+
+ // This second poll must continue consuming the same in-buffer fetch instead of
+ // being treated as stale and drained.
+ ScanRecords secondPoll = logFetcher.collectFetch();
+ List<ScanRecord> secondRecords = secondPoll.records(tb0);
+ assertThat(secondRecords).hasSize(2);
+ assertThat(
+ secondRecords.stream()
+ .map(r -> r.getRow().getInt(0))
+ .collect(Collectors.toList()))
+ .containsExactly(8, 9);
+ assertThat(logFetcher.getLogScannerStatus().getBucketOffset(tb0)).isEqualTo(4L);
+ }
+
+ @Test
+ void testFilterFetchWithMultipleBucketsKeepsOffsetProgressForSameBucket() throws Exception {
+ // Keep poll size small so one completed fetch spans multiple collectFetch calls.
+ clientConf.setInt(ConfigOptions.CLIENT_SCANNER_LOG_MAX_POLL_RECORDS, 2);
+ logFetcher.close();
+ Map<TableBucket, Long> scanBuckets = new HashMap<>();
+ TableBucket tb0 = new TableBucket(tableId, BUCKET_ID_0);
+ TableBucket tb1 = new TableBucket(tableId, BUCKET_ID_1);
+ scanBuckets.put(tb0, 0L);
+ scanBuckets.put(tb1, 0L);
+ logFetcher = createFetcherWithBuckets(scanBuckets);
+
+ List<Object[]> bucket0Rows =
+ Arrays.asList(
+ new Object[] {6, "b0_0"},
+ new Object[] {7, "b0_1"},
+ new Object[] {8, "b0_2"},
+ new Object[] {9, "b0_3"},
+ new Object[] {10, "b0_4"},
+ new Object[] {11, "b0_5"});
+ List<Object[]> bucket1Rows =
+ Arrays.asList(
+ new Object[] {12, "b1_0"},
+ new Object[] {13, "b1_1"},
+ new Object[] {14, "b1_2"},
+ new Object[] {15, "b1_3"},
+ new Object[] {16, "b1_4"},
+ new Object[] {17, "b1_5"});
+ addRecordsToBucket(
+ tb0,
+ LogRecordBatchStatisticsTestUtils.createLogRecordsWithStatistics(
+ bucket0Rows, FILTER_TEST_ROW_TYPE, 0L, DEFAULT_SCHEMA_ID));
+ addRecordsToBucket(
+ tb1,
+ LogRecordBatchStatisticsTestUtils.createLogRecordsWithStatistics(
+ bucket1Rows, FILTER_TEST_ROW_TYPE, 0L, DEFAULT_SCHEMA_ID));
+
+ logFetcher.sendFetches();
+ retry(Duration.ofMinutes(1), () -> assertThat(logFetcher.hasAvailableFetches()).isTrue());
+
+ ScanRecords firstPoll = logFetcher.collectFetch();
+ List<ScanRecord> firstTb0 = firstPoll.records(tb0);
+ List<ScanRecord> firstTb1 = firstPoll.records(tb1);
+ assertThat(firstTb0.size() + firstTb1.size()).isEqualTo(2);
+ TableBucket firstActiveBucket = firstTb0.isEmpty() ? tb1 : tb0;
+ TableBucket firstInactiveBucket = firstTb0.isEmpty() ? tb0 : tb1;
+ assertThat(firstPoll.records(firstActiveBucket)).hasSize(2);
+ assertThat(firstPoll.records(firstInactiveBucket)).isEmpty();
+ assertThat(logFetcher.getLogScannerStatus().getBucketOffset(firstActiveBucket))
+ .isEqualTo(2L);
+ assertThat(logFetcher.getLogScannerStatus().getBucketOffset(firstInactiveBucket))
+ .isEqualTo(0L);
+
+ // Core assertion: second poll should continue from the same bucket (tb0),
+ // not drain it as stale and jump to tb1.
Review Comment:
The comment says the second poll should continue from the same bucket "(tb0)", but the test intentionally allows either bucket to be active first (`firstActiveBucket` may be `tb1`). Update the comment to refer to `firstActiveBucket` (or remove the hard-coded bucket name) to avoid misleading future readers.
--
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: issues-unsubscribe@fluss.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Fix stale fetch detection across poll boundaries [fluss]
Posted by "wuchong (via GitHub)" <gi...@apache.org>.
wuchong merged PR #3053:
URL: https://github.com/apache/fluss/pull/3053
--
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: issues-unsubscribe@fluss.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org