Fix LP tests filters check and add to smoke tests in CI

[Tofel]

FIxes 3 issues:

• invalid check whether CL node has all expected filters (thanks to @reductionista)
• invalid iteration over filters to be registered per upkeep and contract (thanks @reductionista)
• invalid listening circuit breaker logic for log emission

It also adds a couple of sanity checks to make sure that:

• all upkeep ids are unique
• all contract addresses are unique
• all registered filters are unique

Last, but not least I've simplified log await logic (basically query logs from a huge range and repeat until success or timeout) and added LP tests to our integration tests job that runs on each commit.

Once it's merged #11649 can be closed.

[github-actions]

I see that you haven't updated any CHANGELOG files. Would it make sense to do so?

[tateexon]

Two questions:

1. Is it possible to run these tests in parallel?
2. If the answer to the above is no then do we think we will need to add more log poller tests? We have a setup using json files to handle test files with multiple docker based tests that helps us notice when a new test is added but not added to CI with that. With only 3 tests it might be overkill to move to that but if we are going to be adding any more we might want to go that route.

[Tofel]

1. in parallel as in a separate job that runs parallel to this one? I think it should be, but unless we decide we want to run all 6 smoke tests not just 3 of them, then imho it's not needed.
2. @reductionista do you think it makes sense to run 3 tests we have (regular one, replay, chaos) for both fixed and finality tag versions or it's enough if we run any of these 3 tests with fixed depth and rest with finality tag?

[reductionista]

I don't see much point in running any of these tests in CI yet until we add a way to disable backup logpoller in config. I guess we can run them, but we may get a lot of false positives.

[reductionista]

I think once we are ready to run all of them, we should probably run all 6... because there could be different bugs with fixed depth and finality tag for any of those situations

[Tofel]

In the end I did what you suggested, @tateexon

@reductionista I think it's better to run them even if they are not testing LP in isolation, because backup poller is covering whatever issues we might have, we might still catch something.

[reductionista]

Have we tested this to make sure it passes with backup logpoller disabled? Right now, we can only do that manually, so the CI test will have a lot of false positives. But I'll try and make it configurable soon, so we can disable it in CI during these tests as well.

[Tofel]

Have we tested this to make sure it passes with backup logpoller disabled? Right now, we can only do that manually, so the CI test will have a lot of false positives. But I'll try and make it configurable soon, so we can disable it in CI during these tests as well.

@reductionista I did not, do I assume correctly that this should do the trick of disabling backup poller sufficiently?

			// If pollPeriod is set to 1 block time, backup log poller will run once every 100 blocks
			const backupPollerBlockDelay = 10000

[Tofel]

DO NOT MERGE UNITL I REMOVE INCREASED BACKUP POLLER TICK INTERVAL

[Tofel]

@reductionista so... there's a situation, when one tests still fails reliably with backup poller disabled and that's chaos test, in case when it pauses postgres db container during log emission. Some logs might get lost in that case. If backup poller is running they are later correctly processed. When it's not, the test fails. I didn't have time yet to look at node logs to see what's happening there.

[reductionista]

Have we tested this to make sure it passes with backup logpoller disabled? Right now, we can only do that manually, so the CI test will have a lot of false positives. But I'll try and make it configurable soon, so we can disable it in CI during these tests as well.

@reductionista I did not, do I assume correctly that this should do the trick of disabling backup poller sufficiently?

			// If pollPeriod is set to 1 block time, backup log poller will run once every 100 blocks
			const backupPollerBlockDelay = 10000

Doing that it will still run once at the very beginning. I'm not sure if that's a problem, as it would likely just do nothing and happen before the tests actually get started. But just in case I've been doing it like this... so that it will never run:

-	backupLogPollTick := time.After(100 * time.Millisecond)
+  backupLogPollTick := time.After(100 * time.Hour)

[kalverra]

Won't this break the run? I thought names were used to help determine files?

[Tofel]

well, smoke tests pass, no? ;-)

[kalverra]

Did you mean to use the standard errors instead?

[Tofel]

already removed :-)

[cl-sonarqube-production]

SonarQube Quality Gate

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

No Coverage information
0.0% Duplication