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

analyzer: Slow-sync analyzers wait only for _relevant_ fast-sync analyzers to complete #558

Merged
merged 4 commits into from
Nov 7, 2023

Conversation

mitjat
Copy link
Contributor

@mitjat mitjat commented Nov 4, 2023

Task

fixme: slow-sync analyzers start only when all fast-sync analyzers have finished

This PR

This PR changes the sequencing of analyzers to what the title describes.

Previously, all slow-sync analyzers were started only once all fast-sync analyzers completed. But it doesn't make sense for e.eg. Sapphire to wait for fast-sync consensus to complete. These arbitrary delays were expecially noticeable when doing a full reindex (where fast-sync can take a week or more), or if one of the runtimes/consensus encountered an error during fast-sync and got stuck.

@mitjat mitjat force-pushed the mitjat/analyzer-sequencing branch 2 times, most recently from e5c7e37 to 25b25c2 Compare November 4, 2023 04:56
@@ -550,3 +586,14 @@ func Register(parentCmd *cobra.Command) {
analyzeCmd.Flags().StringVar(&configFile, "config", "./config/local.yml", "path to the config.yml file")
parentCmd.AddCommand(analyzeCmd)
}

// For testing purposes only.
type ServiceTester struct {
Copy link
Member

Choose a reason for hiding this comment

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

It's also possible to move the TestSequencing test into the package analyzer (e.g. in sequencing_test.go file). Then the test will have access to package private fields directly and this workaround is not needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah nice, thanks. Converted.

I had looked up a random existing test and figured that the separate _test package is a strong Go convention for tests. I see now that both types of testing (from mypackage_test and from mypackage) are endorsed. And sure, mypackage_test is a little cleaner, but ... not much, with my ServiceTester hack. So, not worth the hassle in this case, IMO.

@mitjat mitjat enabled auto-merge November 7, 2023 01:49
@mitjat mitjat force-pushed the mitjat/analyzer-sequencing branch from d9a0260 to 1c01dc8 Compare November 7, 2023 01:50
@mitjat mitjat merged commit 0cb4781 into main Nov 7, 2023
6 checks passed
@mitjat mitjat deleted the mitjat/analyzer-sequencing branch November 7, 2023 01:57
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.

2 participants