-
Notifications
You must be signed in to change notification settings - Fork 983
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
TestTxEnv::spawn_accounts
should ignore internal addresses
#694
Conversation
b1f7ee1
to
db9a764
Compare
@tzemanovic does this change make sense in terms of accounts? Maybe this fn should ignore implicit accounts as well, in which case it could just accept |
Yeah, I think this is fine and we can also ignore implicit accounts. I prefer this over changing type to The reason we have this helper for wasm is |
Great, have updated to ignore implicit accounts while still accepting |
* james/mainline/dont-spawn-internal-account-vps: Remove comment Update spawn_accounts to ignore implicit addresses Add changelog TestTxEnv::spawn_accounts should ignore internal addresses
…count-vps' (#694) and 'bat/native-vp-test-tooling' (#738) * james/mainline/dont-spawn-internal-account-vps: Remove comment Update spawn_accounts to ignore implicit addresses Add changelog TestTxEnv::spawn_accounts should ignore internal addresses * bat/native-vp-test-tooling: Update tests/src/vm_host_env/tx.rs [feat]: Add multitoken suppor to the TestTxEnv. Add ability to execute wasm blobs on a TestTxEnv in order to test them with native vps
…count-vps' (#694) and 'bat/native-vp-test-tooling' (#738) * james/mainline/dont-spawn-internal-account-vps: Remove comment Update spawn_accounts to ignore implicit addresses Add changelog TestTxEnv::spawn_accounts should ignore internal addresses * bat/native-vp-test-tooling: Update tests/src/vm_host_env/tx.rs [feat]: Add multitoken suppor to the TestTxEnv. Add ability to execute wasm blobs on a TestTxEnv in order to test them with native vps
This test helper writes an empty wasm VP to the
?
subkey for any passed in addresses. We shouldn't need to do this for internal (and maybe also implicit?) addresses, since they shouldn't have a VP in storage. The motivation for this PR is that ineth-bridge-integration
, there will be an internal account (EthBridgePool
) which uses a different Merkle tree to other accounts and cannot have arbitrary bytes written to its?
subkey.