linliu-code opened a new pull request, #781: URL: https://github.com/apache/hudi-rs/pull/781
## What this is Position **2 of 4** in a series porting work from Onehouse's `hudi-rs` fork onto upstream `main`. The series is linear and must land in order: **01 → 02 → 03 → 04**. **Draft** — this cannot merge until #780 and any earlier position land. A PR to `apache/hudi-rs` must be based on a branch in this repository, so the series cannot be stacked on GitHub. This branch therefore carries the earlier positions' commits too, and the "Files changed" view is cumulative. **The work unique to this PR is 2 commits, `04b9235d..650af3bd`** — please review those. ## The bug A point lookup by key loads and decompresses **every data block up to the match**, instead of the one block the index selects. It is not a tuning issue — the block-index probe never matches anything. `Key::content_length()` reads `bytes[0..2]` as a big-endian **i16**, and `find_block_for_key` built its probe with `Key::from_bytes(lookup_key.as_bytes())` — raw content, no length prefix. For any ASCII key both leading bytes are >= `0x20`, so the decoded length is at least `0x2020` = 8224, which always overruns, and `content()` returns the empty slice. An empty-content probe makes `data_block_index.range(..=probe).next_back()` return `None` for every non-empty index key, and the body is `if let Some(entry)` — so it is a **silent no-op**. `scan_block_for_key` then walks block by block. There is no ASCII key for which the old probe worked. The async sibling `blocks_for_keys` already used `Key::from_content`, and its own doc claimed it matched `find_block_for_key`; one of the two was wrong. ## The fix Build the probe with `Key::from_content`, which writes the length prefix the comparison expects. ## Behaviour Unchanged for first key, last key, a key between two blocks (identical `SeekResult` variant and cursor state), a key past EOF, a key before the first key, and over-long keys. A last-key lookup on the 1429-block fixture goes from 1429 block decompressions to 2. **One case does change, and reviewers should weigh it.** Where a non-unique key's copies straddle a block boundary, HBase's midpoint falls back to the right-hand cell, so the separator equals the key itself. The probe now selects the right-hand block and `seek_to` returns a **later** copy where it previously returned the first. `blocks_for_keys` handles this tie by also taking the preceding entry; `find_block_for_key` does not. Mirroring that would cost one extra block read on an exact separator hit. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
