-
Notifications
You must be signed in to change notification settings - Fork 2.6k
ProofRecorder: Implement transactional support #13769
ProofRecorder: Implement transactional support #13769
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not familiar with this part of the codebase enough to approve, but left some comments.
Co-authored-by: Dmitry Markin <[email protected]>
primitives/trie/src/recorder.rs
Outdated
|
||
/// Rollback the latest transaction. | ||
/// | ||
/// If there isn't any transaction, nothing gonna happen. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a log error message would be reasonable? Otherwise we can silently skip API misuses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought of returning an error as well as we do it in OverlayedChanges
. However, I'm not really sure that there is any benefit in it? Even if some calls all the time rollback, nothing breaks? No assumption is broken or similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about getting some information if higher level are not calling start
and rollback/commit
in pairs (e.g. due to some error in logic). W/o error message this case will be silently skipped (maybe making future debugging more tricky).
If this is a conscious design decision that rollback/commit can be called w/o matching start than it is also OK.
Logging error could be some compromise between silently ignoring this case and returning the error.
But maybe my reasoning is too defensive here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
primitives/trie/src/recorder.rs
Outdated
pub fn start_transaction(&self) { | ||
let mut inner = self.inner.lock(); | ||
inner.accessed_nodes_transactions.push(Default::default()); | ||
inner.recorded_keys_transactions.push(Default::default()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is an assumption that lenght of *_transactions
are equal. How about adding assertion here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean both walk in lockstep, but there is no assumption that both have the same length? We never access anything from one to the other assuming that the same index exists there as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant silent assumption - at the end both vecs should have the length of number of transactions, it should never happen that one contains more then other. Assert would be more expressive way to indicate this bound. It would also help if some modifies the code (e.g. return early from rollback/commit_transaction
).
Anyway, feel free to ignore it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
|
||
next_key = next; | ||
} else { | ||
if panic_at_end { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need this condition?
When execute ReadAndPanic(10)
we expect to do 10 reads and then panic right? If we are only able to do 5 reads it looks from the outside as if everything is ok, but something unexpected happened.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we need this.
The docs explicitly mention this:
/// Read X times from the state some data and then panic!
///
/// Returns `Ok` if it didn't read anything.
The point is that you expect it to fail and if it doesn't fail, you know that something didn't work as expected.
Co-authored-by: Sebastian Kunert <[email protected]>
bot fmt |
@bkchr https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2636246 was started for your command Comment |
@bkchr Command |
bot rebase |
Rebased |
bot merge |
Waiting for commit status. |
Merge cancelled due to error. Error: Statuses failed for f7e8b48 |
Co-authored-by: Anton <[email protected]>
bot merge |
Waiting for commit status. |
* TrieRecorder: Start adding support for transactions * Adds `transactions` functions and some test * More tests * Docs * Ensure that we rollback failed transactions in the storage proof * FMT * Update primitives/trie/src/recorder.rs Co-authored-by: Dmitry Markin <[email protected]> * Review comments * Update primitives/trie/src/recorder.rs Co-authored-by: Sebastian Kunert <[email protected]> * ".git/.scripts/commands/fmt/fmt.sh" * For the holy clippy! * Update primitives/trie/src/recorder.rs Co-authored-by: Anton <[email protected]> --------- Co-authored-by: Dmitry Markin <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Anton <[email protected]>
* TrieRecorder: Start adding support for transactions * Adds `transactions` functions and some test * More tests * Docs * Ensure that we rollback failed transactions in the storage proof * FMT * Update primitives/trie/src/recorder.rs Co-authored-by: Dmitry Markin <[email protected]> * Review comments * Update primitives/trie/src/recorder.rs Co-authored-by: Sebastian Kunert <[email protected]> * ".git/.scripts/commands/fmt/fmt.sh" * For the holy clippy! * Update primitives/trie/src/recorder.rs Co-authored-by: Anton <[email protected]> --------- Co-authored-by: Dmitry Markin <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Anton <[email protected]>
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/april-updates-for-substrate-and-polkadot-devs/2764/1 |
* TrieRecorder: Start adding support for transactions * Adds `transactions` functions and some test * More tests * Docs * Ensure that we rollback failed transactions in the storage proof * FMT * Update primitives/trie/src/recorder.rs Co-authored-by: Dmitry Markin <[email protected]> * Review comments * Update primitives/trie/src/recorder.rs Co-authored-by: Sebastian Kunert <[email protected]> * ".git/.scripts/commands/fmt/fmt.sh" * For the holy clippy! * Update primitives/trie/src/recorder.rs Co-authored-by: Anton <[email protected]> --------- Co-authored-by: Dmitry Markin <[email protected]> Co-authored-by: Sebastian Kunert <[email protected]> Co-authored-by: command-bot <> Co-authored-by: Anton <[email protected]>
This implements transactional support for
ProofRecorder
. A transaction can be started withstart_transaction
and then later commited or rolled back. This is important for block producers to not include data from transactions that didn't make it to the block, because they e.g. panicked or similar.Closes: #10222