-
Notifications
You must be signed in to change notification settings - Fork 1
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
Add smoketest to e2e tests #261
Conversation
// This test is failing because the produced transaction is of type cip64. | ||
// I guess this is a problem with the viem internals. | ||
it.skip("cip42 not supported", async () => { | ||
const type = "cip42"; | ||
await verifyTypedTransactions(type); | ||
}).timeout(10_000); |
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.
Interesting and I think your explanation is correct. We could try running the same test against Celo L1 to make sure it's not a change in the chain behaviour that is causing this.
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.
@piersy just to get the explanation right - viem with the new l2 alfajores definitions does not seem to know about "cip42" types and instead produces a cip64 transaction, that then fails the assertion?
I would classify this as a viem bug, since it shouldn't even allow the deprecated `cip42' type and fail early on unknown types (at least in my expectation).
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.
yeah, I'd classify it as a viem bug, i will raise it with the dev tooling team
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.
However viem still needs to be able to send cip42 txs to the celo l1, so it does still need that functionality.
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 it? It could just send CIP-64 without missing any features.
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.
Unless people really want to set the gatewayFee and gatewayFeeRecipient! I'll check with the devtooling team to see what the expected approach for viem is.
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.
You can't set those to non-zero values anymore (celo-blockchain will reject the tx otherwise), so nothing is lost.
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.
Ok, was unaware!
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.
assert.fail("Managed to send unsupported legacy tx with fee currency"); | ||
}).timeout(10_000); | ||
|
||
it.only("legacy create tx with fee currency not supported", async () => { |
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'm not sure if it's worth having this test in addition to the previous one. Chances that tx types behave totally differently between send and create are low and we already test plenty of both in other tests with having to repeat 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.
Hey @karlb I've removed these tests from the viem test and added them in golang since its easier to construct known unsupported transactions in golang, in the golang version I only test send transactions.
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.
Looks good so far! I added some suggestions and questions regarding unsupported tx types.
This branch requires a rebase against celo10
.
// This test is failing because the produced transaction is of type cip64. | ||
// I guess this is a problem with the viem internals. | ||
it.skip("cip42 not supported", async () => { | ||
const type = "cip42"; | ||
await verifyTypedTransactions(type); | ||
}).timeout(10_000); |
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.
@piersy just to get the explanation right - viem with the new l2 alfajores definitions does not seem to know about "cip42" types and instead produces a cip64 transaction, that then fails the assertion?
I would classify this as a viem bug, since it shouldn't even allow the deprecated `cip42' type and fail early on unknown types (at least in my expectation).
Why is the CI workflow with the tests not run for the last commits? The workflow file looks fine to me. |
Hey @karlb, no idea I only made one change to CI which was to run these tests on alfajores. Maybe because the automatic base change or the conflicts it now has? Update: The workflow seemed to get run again after rebasing this on celo10, perhaps it was the existence of conflicts between this and celo10 that caused the workflow to not get run. |
30c3afa
to
7fb90b5
Compare
The smoketest tries all types of transaction for both sends and creates.
Chose a timeout of 16 seconds since the first two tests were taking 8 seconds on Alfajores.
Note that in many cases we were able to remove explicit use of account in transaction creattion because it is "hoisted" in the walletClient. Also removed chain-id and ACC_PRIVKEY as arguments from send_tx.mjs because they are controlled by env vars, which are picked up by the mjs file.
7fb90b5
to
1f87012
Compare
Co-authored-by: Karl Bartel <[email protected]>
Due to the way that viem is structured it is a bad idea for us to block transactions based on the supplied tx attributes, since they may be supported by downstream components such as optimism's custom viem functionality. So rather than trying to test unsupported txs via viem, we now test via golang which allows us full control of the sent transaction, thereby ensuring that rejection is happening at the node level. This commit also extends the error message for deprecated transactions to distinguish between celo legacy and plain legacy transactions.
} | ||
|
||
func parsePrivateKey(privateKey string) (*ecdsa.PrivateKey, error) { | ||
if len(privateKey) >= 2 && privateKey[0] == '0' && (privateKey[1] == 'x' || privateKey[1] == 'X') { |
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.
if len(privateKey) == 66
would also have been an easy way to check for a 0x
-prefixed private key.
83646cc
to
8169cda
Compare
Adds a new workflow that triggers e2e test runs on alfajores once a day, and also in PRs whenever the e2e tests are updated.
8169cda
to
3e50913
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.
Looks great now!
flag.StringVar(&feeCurrency, "fee-currency", "", "address of the fee currency to use") | ||
} | ||
|
||
func TestTxSendingFails(t *testing.T) { |
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.
Will this be discovered by a go test ./...
and then lack the flags?
If so, maybe for now skip the test if the flags are not present and later we can spawn a local test environment if the flags are not present?
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 it has a build flag, so it's only picked up if you specify -tags smoketest
Is there any reason for not having merged this yet, or is it just the merge conflicts? |
I think it just got superseded by our bad block problems, I've updated it now, so should be able to merge shortly 🤞 |
Adds an e2e smoketest that sends value transfer, contract interaction and contract creation transactions for all of the valid transaction types. It also verifies that deprecated transactions (celo legacy & cip42) are not supported. Co-authored-by: Karl Bartel <[email protected]>
Adds an e2e smoketest that sends value transfer, contract interaction and contract creation transactions for all of the valid transaction types. It also verifies that deprecated transactions (celo legacy & cip42) are not supported. Co-authored-by: Karl Bartel <[email protected]>
Adds an e2e smoketest that sends value transfer, contract interaction and contract creation transactions for all of the valid transaction types. It also verifies that deprecated transactions (celo legacy & cip42) are not supported. Co-authored-by: Karl Bartel <[email protected]>
Adds an e2e smoketest that sends value transfer, contract interaction
and contract creation transactions for all of the valid transaction types.
It also verifies that deprecated transactions (celo legacy & cip42) are
not supported.