Skip to content
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

e2e regression tests: HTTP caching proxy, new cases #633

Merged
merged 13 commits into from
Feb 23, 2024
Merged

Conversation

mitjat
Copy link
Contributor

@mitjat mitjat commented Feb 9, 2024

This PR expands our e2e testing capabilities; the motivation is the upcoming support for partial verifications in Sourcify.

The changes are:

  • A new caching HTTP proxy is introduced, based on our existing KVStore. It allows e2e tests to cache HTTP responses (e.g. from sourcify) on an initial run, and then replay them deterministically on every subsequent run.
    • Small refactor: KVStore and the new proxy are moved to a dedicated package.
  • The evmverifier analyzer is now included in e2e tests, using the new proxy.
    • The PR also includes two new db__* test cases that aim to capture the "derived" columns of txs and events, notably the ABI-parsing results.
    • Despite that, there are no diffs between before and after evmverifier. Our current e2e block range does not engage with any contracts that are fully verified 😬
    • This will hopefully change when Andrew7234/e2e extension #627 lands and re-introduces a Damask range, and will certainly change when we support partially-verified contracts (though minimally; there's only 1 partially verified contract that this e2e block range interacts with.
  • The item analyzer sleep logic has changed a little. The old stop_on_empty_queue has been replaced with a duration-based flag ("exit only if the queue has been empty for N seconds"). This is helpful for item analyzers that interact with each other.

@mitjat mitjat changed the title e2e tests: HTTP caching proxy, new cases e2e regression tests: HTTP caching proxy, new cases Feb 9, 2024
@mitjat mitjat force-pushed the mitjat/e2e-cache-http branch 2 times, most recently from a7f90b3 to c7ff623 Compare February 9, 2024 07:35
@@ -512,6 +526,16 @@ func (a *Service) Start() {
ctx, cancelAnalyzers := context.WithCancel(context.Background())
defer cancelAnalyzers() // Start() only returns when analyzers are done, so this should be a no-op, but it makes the compiler happier.

// Start helpers.
for _, helper := range a.helpers {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably also try to gracefully Shutdown() the server helpers in received interrupt, shutting down part. And call Close() on the servers in cleanup.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... not sure it's worth it for these proxies that are intended for e2e testing only and will be shut down simply by killing the whole binary.

But it's good to encourage nice clean code :). Added both, thank you.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Today's end-to-end tests are tomorrow's production features 😁

@@ -149,6 +151,7 @@ func wipeStorage(cfg *config.StorageConfig) error {
type Service struct {
analyzers []SyncedAnalyzer
fastSyncAnalyzers []SyncedAnalyzer
helpers []*http.Server
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be just named (caching) proxies, at least while caching proxies are the only type of helpers there is?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 renamed here and related variables throughout the file.

@pro-wh
Copy link
Collaborator

pro-wh commented Feb 9, 2024

accessing this cache over HTTP, can you talk about this

in existing code that does similar, there's a Go interface and a caching implementation of that

@mitjat mitjat force-pushed the mitjat/e2e-cache-http branch 4 times, most recently from 4d4be77 to c3f6a8f Compare February 16, 2024 01:03
@mitjat mitjat requested a review from ptrus February 16, 2024 01:04
@mitjat mitjat force-pushed the mitjat/e2e-cache-http branch 3 times, most recently from 1075341 to 57204f9 Compare February 16, 2024 01:31
analyzer/item/item.go Show resolved Hide resolved
analyzer/item/item.go Outdated Show resolved Hide resolved
Comment on lines +208 to +209
// NOTE: We upsert rather than update; if the contract is not in the db yet, UPDATE would ignore the
// contract and this analyzer would keep retrying it on every iteration.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm is there a case where the verifier would upsert rather than update? The GetItems query fetches candidates from the chain.evm_contracts table originally

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An insert can happen if sourcify has a contract that we haven't encountered yet, e.g. because we're scanning just a subset of blocks. GetItems no longer limits the items to chain.evm_contracts addresses as of #634 (which is not merged; I accidentally merged it into this branch and then undid that, but I'll duplicate the PR to merge into main once this PR goes in). The reasons for the change are pretty lightweight: we now don't have to worry about what happens as the number of contracts grows, and I found the new flow easier to understand, especially with the added partial/full verification.

tests/e2e_regression/e2e_config_2.yml Outdated Show resolved Hide resolved
tests/e2e_regression/run.sh Outdated Show resolved Hide resolved
tests/e2e_regression/run.sh Outdated Show resolved Hide resolved
Copy link
Collaborator

@pro-wh pro-wh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we switch to a mockable http client later

@mitjat
Copy link
Contributor Author

mitjat commented Feb 22, 2024

can we switch to a mockable http client later

Yeah I'm totally OK with that. Right now the http proxy is only being used for sourcify, and it's a low enough number of requests that we could mock them more explicitly. FWIW, the caching proxy achieves pretty much the same effect, with the debugging downside that it's a lot harder to see the cached/mocked responses.

@mitjat mitjat force-pushed the mitjat/e2e-cache-http branch from 57204f9 to 9e5ad3d Compare February 22, 2024 05:36
@mitjat mitjat requested review from Andrew7234 and pro-wh February 22, 2024 05:36
@mitjat mitjat force-pushed the mitjat/e2e-cache-http branch from 9e5ad3d to 6622cc4 Compare February 22, 2024 05:52
@pro-wh
Copy link
Collaborator

pro-wh commented Feb 22, 2024

what's the item analyzer exit delay for? is there a new test that relies on it?

new config api can't say to do what we did before, you instead have to set a very small delay

@mitjat mitjat force-pushed the mitjat/e2e-cache-http branch 2 times, most recently from cb3c188 to 458d2ca Compare February 22, 2024 20:35
@mitjat
Copy link
Contributor Author

mitjat commented Feb 22, 2024

what's the item analyzer exit delay for? is there a new test that relies on it?

Yeah the e2e. We ideally would want to run in 3 stages ...
#633 (comment)

evm_abi_emerald:               { stop_if_queue_empty_for: 10s } # Give evm_contract_verifier time to fetch ABIs first. The 10s has been enough in practice, but might need to be tuned in the future, especially if the caching proxy has an empty cache.

new config api can't say to do what we did before, you instead have to set a very small delay

True. I worried about it a little at first, but then decided it's just an aesthetic problem, not a functional one. And it only applies to testing. So screw it.

@mitjat mitjat force-pushed the mitjat/e2e-cache-http branch from 458d2ca to aa761a4 Compare February 23, 2024 02:41
@mitjat
Copy link
Contributor Author

mitjat commented Feb 23, 2024

After rebasing on top of #627 and debugging, I realized that our internal Damask Emerald node is currently having issues. I therefore disabled the Emerald part of the new Damask e2e test. This version of this PR still makes e2e tests usefully more comprehensive to help with merging #634.

@mitjat mitjat merged commit 908a841 into main Feb 23, 2024
10 checks passed
@mitjat mitjat deleted the mitjat/e2e-cache-http branch February 23, 2024 02:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants