Skip to content

[Bigtable] Fix Bigtable segment truncation when open end key is startKey + null byte (#39842) - #39843

Open
aa-dit-yuh wants to merge 1 commit into
apache:masterfrom
aa-dit-yuh:fix-bigtable-segment-truncation-null-byte
Open

[Bigtable] Fix Bigtable segment truncation when open end key is startKey + null byte (#39842)#39843
aa-dit-yuh wants to merge 1 commit into
apache:masterfrom
aa-dit-yuh:fix-bigtable-segment-truncation-null-byte

Conversation

@aa-dit-yuh

Copy link
Copy Markdown

Fixes #39842

Problem

When reading from Cloud Bigtable using Apache Beam, reads are processed in buffered segments. When a segment hits buffer memory limits or row limits during a read, Beam pauses the stream and calls truncateRequest to construct a new ReadRowsRequest for the remainder of the key range starting from (start_key_open: lastKey).
For key ranges where the open end key is the start key with an appended null byte (e.g., [K, K\0), common in single-row scans, prefix scans, or dynamic work rebalancing splits), EndPoint.compareTo compares "K\0" to "K", evaluating to endCmp > 0. Because endCmp > 0, truncateRequest did not skip the range after reading key K, and generated a request with (start_key_open: K, end_key_open: K\0).
Cloud Bigtable server validates start_key_open as K\0 and strictly enforces start_key < end_key. Because K\0 < K\0 is false, Bigtable server rejects the request with:
io.grpc.StatusRuntimeException: INVALID_ARGUMENT: Error in field 'row_ranges' : Error in element #0 : start_key must be less than end_key

Solution

In BigtableServiceImpl.BigtableSegmentReaderImpl.truncateRequest, check if rowRange.getEndKeyCase() == END_KEY_OPEN and skip the range if lastKey + "\0" >= rowRange.getEndKeyOpen().

Tests

  • Added unit test testReadRangeWithNullByteEndKeyAtByteLimit in BigtableServiceImplTest.java verifying that ranges with an open null-byte suffix end key are properly recognized as exhausted during truncation without generating invalid requests.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

  • Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
  • Update CHANGES.md with noteworthy changes.
  • If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

Build python source distribution and wheels
Python tests
Java tests
Go tests

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

…Key + null byte (apache#39842)

When truncateRequest splits an open end-key range where endKey == lastKey + "\0",
Bigtable server rejects the next request with INVALID_ARGUMENT (start_key must be
less than end_key) because start_key_open is normalized to lastKey + "\0".
Skip such exhausted open ranges during segment truncation.

Fixes apache#39842
@aa-dit-yuh
aa-dit-yuh force-pushed the fix-bigtable-segment-truncation-null-byte branch from c9c3f55 to c582a81 Compare August 21, 2026 17:41
segment.addRowRanges(newRange.build());
} else {
// Row is split, remove all read rowKeys and split RowSet at last buffered Row
if (rowRange.getEndKeyCase() == RowRange.EndKeyCase.END_KEY_OPEN

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed and fixed a similar issue with reconstructing row key ranges before in the reading large rows logic https://screenshot-v2.corp.google.com/7dli6t427bceg. Maybe it's worth using RowSetUtil.erase to handle this here. But this fix in beam looks correct.

@codecov

codecov Bot commented Aug 21, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 57.10%. Comparing base (a26ecfd) to head (c582a81).
⚠️ Report is 12 commits behind head on master.

Files with missing lines Patch % Lines
.../beam/sdk/io/gcp/bigtable/BigtableServiceImpl.java 80.00% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff            @@
##             master   #39843   +/-   ##
=========================================
  Coverage     57.09%   57.10%           
- Complexity     3639     3654   +15     
=========================================
  Files          1191     1191           
  Lines        192556   192587   +31     
  Branches       3816     3831   +15     
=========================================
+ Hits         109946   109980   +34     
+ Misses        79042    79035    -7     
- Partials       3568     3572    +4     
Flag Coverage Δ
java 72.14% <80.00%> (+0.04%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@github-actions

Copy link
Copy Markdown
Contributor

Assigning reviewers:

R: @Abacn for label java.
R: @mutianf for label bigtable.

Note: If you would like to opt out of this review, comment assign to next reviewer.

Available commands:

  • stop reviewer notifications - opt out of the automated review tooling
  • remind me after tests pass - tag the comment author after tests pass
  • waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Bigtable segment truncation creates invalid range when open end key is startKey + null byte

2 participants