Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RoksDB#multiGetAsList() silently ignores fetching values for keys if db file is corrupt. #12741

Open
praste opened this issue Jun 6, 2024 · 0 comments · May be fixed by #12766
Open

RoksDB#multiGetAsList() silently ignores fetching values for keys if db file is corrupt. #12741

praste opened this issue Jun 6, 2024 · 0 comments · May be fixed by #12766

Comments

@praste
Copy link

praste commented Jun 6, 2024

Note: Please use Issues only for bug reports. For questions, discussions, feature requests, etc. post to dev group: https://groups.google.com/forum/#!forum/rocksdb or https://www.facebook.com/groups/rocksdb.dev

Expected behavior

RoksDB#multiGetAsList() should throw error with code Status.Code.Corruption if db file is corrupt.

Actual behavior

We use rocksdb JNI and have a test that corrupts db files and issues a read using RocksDB#get(), it except throws error with status code Status.Code.Corruption (due to checksum mismatch). However, if a read issued using RoksDB#multiGetAsList() , simply returns a list of size 1 with a null value in it.

Steps to reproduce the behavior

  1. Open RocksDB with paranoid checks
  2. Issue a few writes
  3. Corrupt the db file (you can do it manually)
  4. Issue a read for a key (added in Step 2) using RocksDB#get() and verify it fails with exception with error code Status.Code.Corruption
  5. Now issue a read for a key (added in Step 2) using RocksDB#multiGetAsList(), it doesn't fail with exception with error code Status.Code.Corruption but returns a list with a null element in it
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant