Store swallows DB errors with `.expect()`, propagate Result through storage layer
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- blockchain, distributed-systems
Research direction
Start in crates/storage/src/store.rs by reviewing the Store public methods and the StorageBackend calls that currently use .expect(), then trace their callers in crates/blockchain/src/store.rs. Done means DB errors are returned through the storage and blockchain store layers as Result values rather than causing panics.
Written by the indexing model from the issue text.
Description
crates/storage/src/store.rs calls StorageBackend methods (begin_read, begin_write, put_batch, commit, etc.) but swallows all returned Results via .expect() at 50+ call sites. Any DB error (disk full, corruption, etc.) panics the node instead of being handled gracefully.
The fix is to make Store's public methods return Result<T, Error> and propagate with ?, then update callers in crates/blockchain/src/store.rs accordingly.
Related: #82
Fixing this is also a prerequisite for #266. Without it, the "too many open files" error panics the node rather than being returned as a recoverable error.
- Dominant language
- Rust
- Stars
- 82
- Forks
- 28
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 20
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lambdaclass/ethlambda
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
lambdaclass/ethlambda#529 · 4 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
lambdaclass/ethlambda#521 · 2 comments ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
lambdaclass/ethlambda#609 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
lambdaclass/ethlambda#602 ·
-
performance
Difficulty 4/5 3-5 days Newbie friendliness 55/100
lambdaclass/ethlambda#599 · 1 comment ·
All issues in lambdaclass/ethlambda
Similar issues
-
todo:perf
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
ACP agents get no MCP servers when the thread is created before the project's first worktree loads Openstate:needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
zed-industries/zed#64611 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ontola/atomic-server#1625 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
objectionary/phie#154 ·