You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Things to ensure we include in both the container and in the integration test:
Make sure we have a create & openwallet action in the container, and an assertion about their nonces in the test (create should have nonce == 1 and openwallet should have nonce == 0)
Call approve on an erc20 contract twice with the same value. This should put duplicate/identical state diffs on the tevm side so we can test that we handle it properly (revm won't give us the 2nd duplicate since no state was actually changed)
Check that block number in a solidity contract is the same as the RPC for that transaction. Both in the container for sync as well as after we are live using an alloy test.
Create test that exercises our bugs from revision 0 and assert they still fail. Speak to @aamirpashaa to learn what these look like, for instance sending to multiple new addresses via call and only the first address receiving the value and being created.
Blocks with various combinations of doresources, setrevision and regular transactions all in the same block. Mostly resources and transactions, as gas price changes with doresources, we should make sure that we use the correct gas price when the transaction happens before and after the gas price change. For setrevision could run a transaction that exercises a revision = 0 bug before setrevision, and then run the same transaction after and assert the correct behaviors were performed on revision 0 & 1. Also should test replay/trace transaction methods to ensure they use the correct gas price and revision number as well
Send 2930 AND 1559 transactions in the live test and assert failure, these should be rejected by the EVM contract and/or by the RPC
Send incorrect RLP encoded transactions (trailing zero values, the value field as leading zero, etc..)
Deposit to ZERO address, ensure reth balance is correct after the transaction
Withdraw when ZERO has adequate balance (@aamirpashaa this was our second issue on testnet related to ZERO address balance, need to figure out how to replicate the issue in our integration test)
Non UTF8 memo, console of transactions not involved with eosio.evm. Proper test TBD, just tracking here for now.
Test use pending as the Default Block Parameter against the methods that accept a default block (eth_call, eth_getCode, eth_storageAt, eth_balance, eth_transactionIndex, etc...) See Replace pending block with latest block in all RPC functions #75 for the fix, don't need to assert any values, just that the RPC does not return an error
The text was updated successfully, but these errors were encountered:
Things to ensure we include in both the container and in the integration test:
call
and only the first address receiving the value and being created.value
field as leading zero, etc..)pending
as the Default Block Parameter against the methods that accept a default block (eth_call
,eth_getCode
,eth_storageAt
,eth_balance
,eth_transactionIndex
, etc...) See Replace pending block with latest block in all RPC functions #75 for the fix, don't need to assert any values, just that the RPC does not return an errorThe text was updated successfully, but these errors were encountered: