-
Notifications
You must be signed in to change notification settings - Fork 239
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
svm: improve integration test framework for SIMD83 #3181
Conversation
let target_account_info = next_account_info(accounts_iter)?; | ||
match data[0] { | ||
// print account size | ||
0 => { |
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.
why don't we use enum here with meaningful names for variants?
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.
like the other example programs that already exist, i just wanted to do the simplest thing possible. theyre only used for one set of tests and arent expected to change, and are trivial 20-40 line single-file programs that arent part of the toplevel monorepo Cargo.toml
workspace and arent imported by anything. i have helpers in svm/tests/integration_test.rs
tho
} | ||
// reallocate account | ||
3 => { | ||
let new_size = usize::from_le_bytes(data[1..9].try_into().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.
Do you avoid using borsh to avoid associated deserialization cost?
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.
cost isnt a concern, as above its just doing the simplest thing possible
match data[0] { | ||
// print account size | ||
0 => { | ||
msg!( |
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 you print here for debug purpose or to imitate reading the data without writing back? In case of the second, I believe msg
cost is not negligible and instead I would call std::ptr::read_volatile
which prevents compiler to optimize unused code (which doesn't happen with our compiler anyways).
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 use this to check which specific transactions cause accounts to be deallocated or reallocated in a multi-transaction batch. svm integration tests can directly read transaction logs off the execution result
fn process_instruction( | ||
_program_id: &Pubkey, | ||
accounts: &[AccountInfo], | ||
data: &[u8], |
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.
Does data
contains some random number to prevent duplicate txs? This is not the only way but the simplest
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 check on length - if need that functionality easy to just append random bytes at the end; program has no need to read them
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, duplicates arent a concern because all the svm integration tests are structured like "here is a specific list of transactions to execute, heres what the execution results, final account states, and log messages should be"
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.
Changes look fine to me; there seem to be a few unrelated changes here which made reviewing it a bit confusing tbh, but not going to block on it.
Commented a few questions
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.
never a fan of adding binary objects to the repo, but it seems this is the common practice for svm tests
fn process_instruction( | ||
_program_id: &Pubkey, | ||
accounts: &[AccountInfo], | ||
data: &[u8], |
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 check on length - if need that functionality easy to just append random bytes at the end; program has no need to read them
@@ -682,8 +706,12 @@ fn simple_nonce(enable_fee_only_transactions: bool, fee_paying_nonce: bool) -> V | |||
let mut fee_payer_data = AccountSharedData::default(); | |||
fee_payer_data.set_lamports(LAMPORTS_PER_SOL); | |||
test_entry.add_initial_account(fee_payer, &fee_payer_data); | |||
} else if rent_paying_nonce { | |||
assert!(fee_paying_nonce); |
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.
not sure I understand the connection between fee paying and rent paying for the nonce 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.
a nonce account used as a transaction fee-payer that would be brought one lamport below rent exemption if it was allowed to pay for the transaction
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.
oh you mean the assert, its just to make sure the annoyingly complex lambda wasnt misused. if you wanted a rent-paying non-fee-paying nonce you wouldnt add LAMPORTS_PER_SIGNATURE
, or else youd still have a rent-exempt nonce, and might write a test that doesnt test what it means to test. but no tests need an account like that so i didnt add a branch for it
// 5: rent-paying nonce fee-payers are also not charged for fee-only transactions | ||
if enable_fee_only_transactions && fee_paying_nonce { |
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.
this seems exactly the same as above, or am I missing something?
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 im overly paranoid but case 4 uses a real program id, so account loading can succeed, but the transaction is discarded because charging for it would make the valid nonce fee-payer become invalid. case 5 uses a fake program id, which aborts account loading, so we test that with fee-only transactions enabled there isnt any kind of short-circuit code path that would cause it to pay fees
i wanted to be very thorough about this because there are a number of edge cases to cover if a) a regular fee-payer has to pay rent, and b) nonce accounts are mutated in-batch, so we want to be absolutely sure the overlap of those two things is impossible
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.
thanks. I just didn't notice the difference in 2nd arge of mk_nonce_transaction
sorry this is a bit confusing out of context, the goal is purely to make reviewing #3146 easier (since it is extremely large) by a) reducing it by a few hundred loc, and b) making its diff of |
dbd9cf1
to
ae63530
Compare
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
* svm: improve integration test framework for SIMD83 * merge write program match expressions * clarify nonce comment
Problem
the first simd83 pr draft (#3146) has a nearly 2500 line diff. since the new tests im adding for transaction batches with reader-writer and writer-writer account overlap require some changes and additions to the svm integration test framework, im pulling as much as i can out into a separate pr to go in first
Summary of Changes
write-to-account
, which can read, write, deallocate, and reallocate an account