codope opened a new pull request, #13177:
URL: https://github.com/apache/hudi/pull/13177

   ### Change Logs
   
   When performing random access lookups against an HFile, callers often do:
   1. seekTo() to position at the first record at the start of the file.
   2. seekTo(key) to floor or find an exact match.
   3. examine the return code (SEEK_TO_FOUND / SEEK_TO_IN_RANGE / 
SEEK_TO_BEFORE_FIRST_KEY / SEEK_TO_EOF).
   
   However, if you issue two non‐existent lookups in a row, and the second 
lookup is for a key that is lexicographically smaller than the key where cursor 
is pointed after the first lookup, then the second seekTo(key) would throw an 
exception:
   ```
   Caused by: java.lang.IllegalStateException: The current lookup key is less 
than the current position of the cursor, i.e., backward seekTo, which is not 
supported and should be avoided. 
key=UTF8StringKey{aZud4Oj9wxA=AZcHyzibzy8=bJfAFKIt2udY/eEKkDkFbg==} 
cursor=HFilePosition{offset=10503431, 
keyValue=Option{val=KeyValue{key=Key{aZud4Oj9wxA=AZcHyzibzy8=bLXWAR+d0ui0DMuh0uAXbw==}}}}
        at 
org.apache.hudi.io.hfile.HFileReaderImpl.seekTo(HFileReaderImpl.java:173)
        at 
org.apache.hudi.io.storage.HoodieNativeAvroHFileReader$RecordByKeyIterator.hasNext(HoodieNativeAvroHFileReader.java:404)
   ...
   ```
   That happened because we only treated "backward" relative to the very first 
block in the file, not relative to whichever block we’d just loaded via 
`floorEntry(key)`.
   
   This PR fixes the check for `isAtFirstKey` (now renamed to `isAtBlockStart`) 
to also consider whether the cursor’s offset equals the start of the 
_**current**_ data block.
   
   So, the changed behavior is as follows;
   - Lookups < block’s first key now yield SEEK_TO_BEFORE_FIRST_KEY instead of 
exception.
   - All other semantics (exact match, in‐range, beyond‐last => IN_RANGE or EOF 
as before) remain unchanged.
   - No additional I/O overhead; only a small offset comparison in the guard.
   
   ### Impact
   
   Downstream readers (e.g., RecordByKeyIterator for index lookups) now safely 
handle arbitrary lookup without reader re‐initialization or catch‐and‐reset 
hacks.
   
   ### Risk level (write none, low medium or high below)
   
   low
   
   ### Documentation Update
   
   _Describe any necessary documentation update if there is any new feature, 
config, or user-facing change. If not, put "none"._
   
   - _The config description must be updated if new configs are added or the 
default value of the configs are changed_
   - _Any new feature or user-facing change requires updating the Hudi website. 
Please create a Jira ticket, attach the
     ticket number here and follow the 
[instruction](https://hudi.apache.org/contribute/developer-setup#website) to 
make
     changes to the website._
   
   ### Contributor's checklist
   
   - [ ] Read through [contributor's 
guide](https://hudi.apache.org/contribute/how-to-contribute)
   - [ ] Change Logs and Impact were stated clearly
   - [ ] Adequate tests were added if applicable
   - [ ] CI passed
   


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