I am hitting what looks like two different cases of panics when trying to close the database with "proper" timing.
fs.flush().await?;
fs.db.close().await?;
First case:
2025-11-14T16:38:57.028364Z INFO zerofs::cli::server: Received SIGINT, shutting down gracefully...
thread 'tokio-runtime-worker' panicked at /root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/slatedb-0.9.0/src/compactor_executor.rs:253:22:
failed to send compaction progress: SendError { .. }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2025-11-14T16:38:57.311348Z ERROR slatedb::utils: spawned task panicked. [name=compactor_executor, panic=failed to send compaction progress: SendError { .. }]
thread 'tokio-runtime-worker' panicked at /root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/slatedb-0.9.0/src/compactor_executor.rs:321:22:
failed to send compaction finished msg: SendError { .. }
2025-11-14T16:38:57.311542Z ERROR slatedb::compactor_executor: shutdown error in compaction task [error=JoinError::Panic(Id(152), "failed to send compaction finished msg: SendError { .. }", ...)]
Second case:
thread 'tokio-runtime-worker' (4006131) panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bytes-1.10.1/src/bytes.rs:396:9:
range end out of bounds: 4333922 <= 4194304
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tokio-runtime-worker' (4006146) panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bytes-1.10.1/src/bytes.rs:396:9:
range end out of bounds: 8546044 <= 8541020
thread 'tokio-runtime-worker' (4006140) panicked at /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bytes-1.10.1/src/bytes.rs:396:9:
range end out of bounds: 4307965 <= 4194304
thread 'tokio-runtime-worker' panicked at /root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bytes-1.10.1/src/bytes.rs:396:9:
range end out of bounds: 10530200 <= 10366589
stack backtrace:
I am hitting what looks like two different cases of panics when trying to close the database with "proper" timing.
First case:
Second case: