Sled: can't trap, handle the error using `?` when creating a new tree after deliberately modifying the db

Created on 25 Aug 2020  路  2Comments  路  Source: spacejam/sled

expected result

a Result or Option instead of a panic when the db/tree is corrupted or deliberately modified not by sled

actual result

thread 'main' panicked at '57 >= 83', /../github.com-1ecc6299db9ec823/sled-0.34.2/src/pagecache/snapshot.rs:325:9
https://github.com/spacejam/sled/blob/v0.34.2/src/pagecache/snapshot.rs#L325-L330

sled version

v0.34.2

rustc version

rustc 1.45.2 (d3fb005a3 2020-07-31)

operating system

macOS Catalina

minimal code sample that helps to reproduce the issue

fn main() {
    // this directory will be created if it does not exist
    let path = "/tmp/yy";

    let db = match sled::Config::new()
        .temporary(false)
        .path(path)
        .mode(sled::Mode::LowSpace)
        .use_compression(true)
        .open()
    {
        Ok(db) => db,
        Err(e) => {
            eprintln!("{}", e);
            std::process::exit(3);
        }
    };


Cargo.toml dependecies

[dependencies] sled = {version = "0.34.2", features = ["compression"] }

I was expecting to catch and handle the error in cases where the database has been corrupted, for testing this I modified the db file located under the defined path(/tmp/yy/db), I deleted some random rows and after running again the code it panics.

bug

All 2 comments

I agree that this should return an Error::Corruption instead of panicking. The right approach is to add a new randomized test that will corrupt files randomly and assert that the code never panics.

An immediate fix is being worked on in https://github.com/spacejam/sled/pull/1170 and will be released shortly

Was this page helpful?
0 / 5 - 0 ratings

Related issues

goldenMetteyya picture goldenMetteyya  路  3Comments

D1plo1d picture D1plo1d  路  5Comments

spacejam picture spacejam  路  4Comments

rubdos picture rubdos  路  8Comments

thedrow picture thedrow  路  5Comments