RocksDB storage helpers panic on unexpected input instead of returning errors

[huitseeker]

The subtree_db_key and subtree_cf helper functions panic on unexpected input (unsupported depths or missing column families) instead of returning proper errors. If corrupted database state or an unexpected NodeIndex depth is encountered, the panic crashes the process rather than allowing graceful error handling.

The root cause is using panic! and .expect() for error conditions that could arise from corrupted data. At miden-crypto/src/merkle/smt/large/storage/rocksdb.rs:228, subtree_db_key panics on any depth not in {24, 32, 40, 48, 56}. At line 248, subtree_cf uses .expect("CF handle missing") which panics if the column family doesn't exist.

Both cases turn recoverable storage errors into crashes. A corrupted database could contain a subtree with an invalid depth, or a missing column family could indicate database schema mismatch. These should be reported as StorageError to allow the caller to handle them appropriately.

To fix this, return Result<_, StorageError> from both helpers and propagate errors using ?. For subtree_db_key, return StorageError::Unsupported for invalid depths. For subtree_cf, the .expect() should just be removed since cf_handle already returns Result.

[bobbinth]

Note that with #1499, RocksDB backend will move into miden-node. So, this issue may be more appropriate there.

[huitseeker]

This should move to 0xMiden/node. The copied RocksDB backend in PR #1499 still panics on unsupported subtree depth and missing column family, so the crash risk now lives there.

[Mirko-von-Leipzig]

I don't understand how such errors would ever be recoverable?