Consider the case where we issue a set_values with a delete of a leaf that is not in the triedb - is this a valid operation?
If it is a valid operation, it seems like it can fail to update branch pointers, like so:
- we traverse the trie and hit a branch node that shares path with the delete, the only item in changes:
|
let result = self.handle_child_node_traversal( |
- the next hop is a different page: https://github.com/base/triedb/blob/66e5e076e6e02f3030e1ea16343e0aca97b39248/src/storage/engine/handlers.rs#L168C30-L168C48
- set_values_in_page clones the page:
|
let page = self.get_mut_clone(context, page_id)?; |
- set_values_in_cloned_page loads the node (an account leaf for example) and decides they have no shared prefix (since the delete was for a node that doesn't exist) - notably, changes_left and changes_right are both empty:
|
return self.set_values_in_cloned_page( |
- recursion happens and returns NoChange:
|
return Ok(PointerChange::None); |
- NoChange bubbles up, but the page change that
set_values_in_page caused with the clone+orphan is forgotten:
|
match child_pointer_change { |
Consider the case where we issue a
set_valueswith a delete of a leaf that is not in the triedb - is this a valid operation?If it is a valid operation, it seems like it can fail to update branch pointers, like so:
triedb/src/storage/engine/handlers.rs
Line 109 in 66e5e07
triedb/src/storage/engine/write.rs
Line 88 in 66e5e07
triedb/src/storage/engine/write.rs
Line 192 in 66e5e07
triedb/src/storage/engine/write.rs
Line 170 in 66e5e07
set_values_in_pagecaused with the clone+orphan is forgotten:triedb/src/storage/engine/handlers.rs
Line 176 in 66e5e07