feat: implement in-memory storage backend#183
Conversation
d7fe4bc to
56afdf7
Compare
955e4f1 to
7731223
Compare
3e311c7 to
5ef8999
Compare
7731223 to
a737cf2
Compare
5ef8999 to
84c813c
Compare
a737cf2 to
1eef699
Compare
84c813c to
9ca3987
Compare
1eef699 to
1c7a7a3
Compare
Wiz Scan Summary
To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension. |
1c7a7a3 to
f336fc3
Compare
| let mut collected_entries: Vec<(Nibbles, BranchNodeCompact)> = | ||
| if let Some(addr) = hashed_address { | ||
| // Storage trie cursor | ||
| for ((block, address, path), branch) in &storage.storage_branches { |
There was a problem hiding this comment.
Shouldn't we merge the changes from trie_updates for all blocks up to the specified max_block_number?
There was a problem hiding this comment.
I think this should merge them all already. The BTreeMap is sorted by block number ASC, so when we collect all the entries, it will choose the latest block <= max_block_number.
There was a problem hiding this comment.
If I understand correctly, we are storing live updates only in the trie_updates BTreeMap. We aren't saving data to storage_branches BTreeMap in the live syncing.
Hence live updates changes won't be visible to the cursor since cursor is only reading storage_branches BTreeMap
There was a problem hiding this comment.
ah I see, that should be saved to *_branches and hashed_*. The trie_updates and post_states are just indexes from block number to the slots/trie nodes changed for pruning/reorgs.
There was a problem hiding this comment.
Thanks. Will review it.
| .collect() | ||
| } else { | ||
| // Account trie cursor | ||
| for ((block, path), branch) in &storage.account_branches { |
|
does this pr reference any issue? |
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176 This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on #183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Based on op-rs/op-reth#183 This PR adds a backfill job that accepts a DB transaction and copies the current state to the database. The transaction ensures we see a consistent view of the database at the current block, even if the node is syncing. This requires `--db.read-transaction-timeout 0`. This currently doesn't handle interrupting the job because the state may update while syncing and may read a different version of the database upon restart. --------- Co-authored-by: Arun Dhyani <dhyaniarun7@gmail.com> Co-authored-by: Emilia Hane <elsaemiliaevahane@gmail.com>
Ref #176
This PR adds an in-memory storage backend and tests that work with any storage backend. We can easily add more test cases to the file to test against a future SQLite backend.