svm: improve integration test framework for SIMD83 by 2501babe · Pull Request #3181 · anza-xyz/agave

2501babe · 2024-10-15T16:51:35Z

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

add a new example program, write-to-account, which can read, write, deallocate, and reallocate an account
add convenience helpers for this new program to the integration test file
add a test confirming that nonce fee-payers must be rent exempt, to complement upcoming tests for what happens when a regular rent-paying fee-payer is deallocated as a side effect of transaction execution
add compute budget and program size helper, for upcoming tests for what happens when an account is reallocated mid-batch
improve some ergonomics, eg not advancing expected nonce state for discarded transactions, and checking transaction execution status before account states to aid test-driven development

KirillLykov · 2024-10-16T13:28:10Z

+    let target_account_info = next_account_info(accounts_iter)?;
+    match data[0] {
+        // print account size
+        0 => {


why don't we use enum here with meaningful names for variants?

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

KirillLykov · 2024-10-16T13:29:16Z

+        }
+        // reallocate account
+        3 => {
+            let new_size = usize::from_le_bytes(data[1..9].try_into().unwrap());


Do you avoid using borsh to avoid associated deserialization cost?

cost isnt a concern, as above its just doing the simplest thing possible

KirillLykov · 2024-10-16T13:39:45Z

+    match data[0] {
+        // print account size
+        0 => {
+            msg!(


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).

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

KirillLykov · 2024-10-16T13:42:46Z

+fn process_instruction(
+    _program_id: &Pubkey,
+    accounts: &[AccountInfo],
+    data: &[u8],


Does data contains some random number to prevent duplicate txs? This is not the only way but the simplest

no check on length - if need that functionality easy to just append random bytes at the end; program has no need to read them

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"

apfitzge

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

apfitzge · 2024-10-16T13:18:52Z

never a fan of adding binary objects to the repo, but it seems this is the common practice for svm tests

apfitzge · 2024-10-16T14:23:05Z

+fn process_instruction(
+    _program_id: &Pubkey,
+    accounts: &[AccountInfo],
+    data: &[u8],


no check on length - if need that functionality easy to just append random bytes at the end; program has no need to read them

apfitzge · 2024-10-16T14:27:14Z

            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);


not sure I understand the connection between fee paying and rent paying for the nonce here.

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

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

apfitzge · 2024-10-16T14:31:05Z

+    // 5: rent-paying nonce fee-payers are also not charged for fee-only transactions
+    if enable_fee_only_transactions && fee_paying_nonce {


this seems exactly the same as above, or am I missing something?

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

thanks. I just didn't notice the difference in 2nd arge of mk_nonce_transaction

2501babe · 2024-10-16T14:46:16Z

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 integration_test.rs purely adding more tests, with no changes to the code that runs tests

apfitzge

lgtm

* svm: improve integration test framework for SIMD83 * merge write program match expressions * clarify nonce comment

2501babe mentioned this pull request Oct 15, 2024

svm: modularize integration test runner #3183

Merged

2501babe self-assigned this Oct 15, 2024

2501babe marked this pull request as ready for review October 15, 2024 18:53

2501babe requested a review from apfitzge October 15, 2024 18:53

KirillLykov reviewed Oct 16, 2024

View reviewed changes

apfitzge reviewed Oct 16, 2024

View reviewed changes

svm: improve integration test framework for SIMD83

1243830

apfitzge reviewed Oct 17, 2024

View reviewed changes

Comment thread svm/tests/integration_test.rs Outdated

merge write program match expressions

ae63530

2501babe force-pushed the 20241015_svminteg_imprv branch from dbd9cf1 to ae63530 Compare October 17, 2024 18:07

clarify nonce comment

3d92aa0

apfitzge approved these changes Oct 17, 2024

View reviewed changes

2501babe added the automerge automerge Merge this Pull Request automatically once CI passes label Oct 17, 2024

mergify Bot merged commit b032f78 into anza-xyz:master Oct 17, 2024

2501babe deleted the 20241015_svminteg_imprv branch October 17, 2024 20:54

ray-kast pushed a commit to abklabs/agave that referenced this pull request Nov 27, 2024

svm: improve integration test framework for SIMD83 (anza-xyz#3181)

f97c25f

* svm: improve integration test framework for SIMD83 * merge write program match expressions * clarify nonce comment

		// 5: rent-paying nonce fee-payers are also not charged for fee-only transactions
		if enable_fee_only_transactions && fee_paying_nonce {

Conversation

2501babe commented Oct 15, 2024

Problem

Summary of Changes

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KirillLykov Oct 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apfitzge left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

2501babe Oct 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

2501babe Oct 16, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

2501babe commented Oct 16, 2024

Uh oh!

Uh oh!

apfitzge left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

KirillLykov Oct 16, 2024 •

edited

Loading

2501babe Oct 16, 2024 •

edited

Loading

2501babe Oct 16, 2024 •

edited

Loading