Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug(engine): persisted executed block retrieval #11251

Closed
Tracked by #8742
rkrasiuk opened this issue Sep 26, 2024 · 0 comments · Fixed by #11265
Closed
Tracked by #8742

bug(engine): persisted executed block retrieval #11251

rkrasiuk opened this issue Sep 26, 2024 · 0 comments · Fixed by #11265
Assignees
Labels
C-bug An unexpected or incorrect behavior

Comments

@rkrasiuk
Copy link
Member

Description

Currently, new tree constructs executed persisted blocks by calling provider.get_state

let SealedBlockWithSenders { block, senders } = self
.provider
.sealed_block_with_senders(hash.into(), TransactionVariant::WithHash)?
.ok_or_else(|| ProviderError::HeaderNotFound(hash.into()))?;
let execution_output = self
.provider
.get_state(block.number)?
.ok_or_else(|| ProviderError::StateForNumberNotFound(block.number))?;
let hashed_state = execution_output.hash_state_slow();

However, this function can only retrieve the state for blocks at tip as it only looks at plain state tables

// This is not working for blocks that are not at tip. as plain state is not the last
// state of end range. We should rename the functions or add support to access
// History state. Accessing history state can be tricky but we are not gaining
// anything.
let mut plain_accounts_cursor = self.tx.cursor_read::<tables::PlainAccountState>()?;
let mut plain_storage_cursor = self.tx.cursor_dup_read::<tables::PlainStorageState>()?;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug An unexpected or incorrect behavior
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants