Add smoketest to e2e tests by piersy · Pull Request #261 · celo-org/op-geth

piersy · 2024-10-18T18:19:45Z

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.

e2e_test/js-tests/test_viem_smoketest.mjs

karlb · 2024-10-21T06:23:52Z

e2e_test/js-tests/test_viem_smoketest.mjs

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


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.

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

yeah, I'd classify it as a viem bug, i will raise it with the dev tooling team

However viem still needs to be able to send cip42 txs to the celo l1, so it does still need that functionality.

Does it? It could just send CIP-64 without missing any features.

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.

You can't set those to non-zero values anymore (celo-blockchain will reject the tx otherwise), so nothing is lost.

Ok, was unaware!

@karlb @ezdac I've moved this test into the smoketest_unsupported_txs golang test. Where we can be sure that we are sending an invalid transaction, and therefore ensure that the server correctly rejects it.

e2e_test/js-tests/test_viem_smoketest.mjs

karlb · 2024-10-21T06:32:59Z

e2e_test/js-tests/test_viem_smoketest.mjs

+			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 () => {


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.

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.

e2e_test/test_smoketest.sh

ezdac

Looks good so far! I added some suggestions and questions regarding unsupported tx types.
This branch requires a rebase against celo10.

e2e_test/js-tests/test_viem_smoketest.mjs

ezdac · 2024-10-21T23:08:06Z

e2e_test/js-tests/test_viem_smoketest.mjs

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


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

e2e_test/js-tests/test_viem_smoketest.mjs

.github/workflows/ci.yaml

karlb · 2024-10-22T13:23:06Z

Why is the CI workflow with the tests not run for the last commits? The workflow file looks fine to me.

piersy · 2024-10-22T13:33:15Z

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.

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.

e2e_test/js-tests/test_viem_smoketest.mjs

e2e_test/test_smoketest.sh

Co-authored-by: Karl Bartel <karl.bartel@clabs.co>

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.

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 <karl.bartel@clabs.co>

…261) Co-authored-by: Karl Bartel <karl.bartel@clabs.co> e2e(js): Add mainnet & baklava config in e2e viem setup (#331, #340)

This should normally not happen, but we have to make sure that such a rare case won't crash geth nodes are cause stuck transactions that will get re-executed on every block. e2e(fee_currency): Refactor fee currency e2e tests (#212, #258) Refactors debug fee currency deployment ensuring fee currency cleanup. The geth-devmode predeployed "oracle3" is reused throughout the e2e tests for all dynamically deployed fee-currencies. However the tested fee-currencies are never removed from the FeeCurrencyDirectory. This causes the node to try to query exchange-rates for the leftover fee-currencies. This fails, because the oracle associated with the old fee-currency has a different token address assigned and thus causes a revert. This issue is not critical and only causes emission of a log message and some unneccessary evm calls, but it is better practice to clean up the fee-currency from the directory anyways. Co-authored-by: Maximilian Langenfeld <15726643+ezdac@users.noreply.github.com> [squash]: e2e(ci): update foundry version to v1.1.0 (#380) e2e(fee_currency): Update error message assertion (#363) e2e(fee_currency): Fix account balance check (#266) e2e(fee_currency): Import viem_setup.mjs instead of setup viem in send_tx.mjs (#261) Co-authored-by: Karl Bartel <karl.bartel@clabs.co> e2e(runner|fee_currency): Fix failing e2e test (#371) * Add Random in BlockContext to enable Merge and Shanghai fork in TryDebitFees * Add --broadcast option in deploy_fee_currency to ensure fee currency is deployed in e2e * Fix log assertion in e2e * Add several e2e tests for admin blocking API * Remove broadcast