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

Return PrunedError when trying to read unavailable historical data #13014

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

antonis19
Copy link
Member

@antonis19 antonis19 commented Dec 5, 2024

Certain RPC queries require access to historical data, however this data may have been deleted in a full node due to pruning. To avoid unexpected errors down the line it would be better to throw a more indicative error earlier in the request handling flows when the HistoryReaderV3 is created.

Issue: #12977

Copy link
Collaborator

@AskAlexSharov AskAlexSharov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for pushing it forward - it will greatly improve UX and reduce Support team burden.

erigon-lib/state/domain.go Outdated Show resolved Hide resolved
@@ -1727,6 +1727,18 @@ func (a *Aggregator) BuildFilesInBackground(txNum uint64) chan struct{} {
return fin
}

func (ac *AggregatorRoTx) StartingTxNum() uint64 {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we must not think that all domains are equal:

  • commitment domain already has disabled history
  • we may have new domains in future
  • Historical exec does read: acc, storage, code, receipt. but it doesn’t read commitment domain.

so, maybe we must accept list of domain names as a parameter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is when we create the historical state reader using rpchelper.CreateHistoryStateReader we don't pass the domains we need for it, just the txNum.

If I make the start tx num calculation function take a list of domain names as a parameter, that means that list needs to be specified by the caller of rpchelper.CreateHistoryStateReader which is not very optimal I think.

What I notice is that HistoryReaderV3 is mainly used as a StateReader, and seems to only read from:

  • accounts
  • storage
  • code

Receipts and commitment history don't seem to be accessed.

Do you think it would make sense to consider accounts, storage, and code history in unison (as a single reader), and have separate readers for receipts and commitment? (this I can ignore receipts and commitment history startingTxNum for this reader)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HistoryStateReader - is the "buisness-logic thing" - means only HistoryStateReader knows which domains it using. HistoryStateReader - has only 1 use-case: execution of historical blocks (other places in code can call GetAsOf method directly). And re-execution require only acc/code/storage domains.

which is not very optimal I think - what do you mean?

Don't forget that Commitment history is disabled - even on archive mode.

and have separate readers for receipts and commitment? - we already have: ReceiptGenerator. If some code need commitment - it can call Get or GetAsOf directly - don't need reader (or need some very-specialized reader).

Any idea on: what to do in --prune.mode=minimal? Here can have 0 history files but some history in DB (1 step).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// return the earliest known txnum in state history (excluding commitment and receipt history) - Commitment history is disabled (no history files. no history data in db).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Precisely because we don't make use of Commitment history or Receipts history, I am grouping Accounts, Storage and Code together because they are intertwined together. We can add additional methods in the future to get the start of Commitment and Receipts history.

turbo/rpchelper/helper.go Outdated Show resolved Hide resolved
@antonis19 antonis19 force-pushed the check-txnum-state-reader branch from eb7b973 to bf6f02b Compare December 11, 2024 11:04
@antonis19 antonis19 requested a review from yperbasis December 11, 2024 12:53
Copy link
Member

@shohamc1 shohamc1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@antonis19 antonis19 enabled auto-merge (squash) December 11, 2024 13:52
@@ -464,6 +464,9 @@ type TemporalTx interface {
Tx
TemporalGetter

// return the earliest known txnum in state history (excluding commitment and receipt history)
StateHistoryStartFrom() uint64
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tx/TemporalTx interface - is low-level interface. it must be business-logic agnostic.
"State" - it's something from Ethereum business-dictionary.
TemporalTx must not know - which domains are exist (or may be created in future). It also doesn't know what stored inside each domain (for TemporalTx - it's just some keys/values/timestamps).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point, I'll check if I can make it more general, i.e. HistoryStartFrom()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants