-
Notifications
You must be signed in to change notification settings - Fork 249
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
chore: update to 0.13.0 nearcore crates #820
Conversation
Needed to retain functionality for unit testing within the SDK near/near-sdk-rs#820 is the matching PR to the SDK (and other changes needed when updating for reference)
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.
LGTM
fn pub_key_conversion(key: &VmPublicKey) -> PublicKey { | ||
// Hack by serializing and deserializing the key. This format should be consistent. | ||
String::from(key).parse().unwrap() | ||
} |
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.
feels like this conversion could also fall into the trap of semantics changing from under us if near_crypto::PublicKey
string conversion ever changes, so a test might be worthy. This isn't too important though since this is only gonna be in unit tests, so leaving this one up to you if you wanna add
#[allow(dead_code)] | ||
#[cfg(test)] | ||
pub(crate) static mut NEXT_TRIE_OBJECT_INDEX: u64 = 0; | ||
/// Get next id of the object stored on trie. | ||
#[allow(dead_code)] | ||
#[cfg(test)] |
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.
hmm, since this is the test_utils
module don't we want to just expand further and say the whole module is under #[cfg(test)]
instead?
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.
no, because these are annotated with this because they are just used within the crate, where the others are used because they are used externally (you can't use things marked with cfg(test)
externally
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.
Seems very reasonable to me
PrimitivesAction::DeleteKey(k) => { | ||
VmAction::DeleteKey { public_key: pub_key_conversion(&k.public_key) } | ||
} | ||
PrimitivesAction::DeleteAccount(a) => { | ||
VmAction::DeleteAccount { beneficiary_id: a.beneficiary_id.parse().unwrap() } | ||
} |
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.
Very small nit: any reason why you didn't inline these like you have done with others above? Sorry for nitpicking, this is just triggering my OCD :)
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.
it's just default formatting, the line is too long and it pushes it like this
WIP since the crates haven't been released, opening PR for visibility and for input as a few things had to change:
receipt_indices
, and addednon_exhaustive
outcome
function on theMockedBlockchain
created_receipts
andlogs
(nothing too breaking)Most importantly, this change comes with the functionality of having the correct
promise_batch_action_function_call_weight
implementation by using the new protocol feature