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

refactor(all): improve SummaryKeys management #1491

Merged
merged 18 commits into from
Feb 7, 2024
Merged

Conversation

bassosimone
Copy link
Contributor

@bassosimone bassosimone commented Feb 6, 2024

While approaching ooni/probe#2667, I recognized that the approach we're using to generate SummaryKeys is redundant, verbose, and fragile. This diff attempts to improve our implementation.

We define new types for generating summary keys and engine.MeasurementSummaryKeys to either return the proper summary keys, if the experiment TestKeys support that or return a default value.

While there, disable the flaky throttlingWithHTTP QA check (see ooni/probe#2668).

Lots of errors and bugfixes still needed but let's publish
the branch first and then continue hammering it.

See ooni/probe#2667
// SummaryKeys contains summary keys for this experiment.
//
// Note that this structure is part of the ABI contract with ooniprobe
// therefore we should be careful when changing it.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We can safely remove this comment because we have moved the implicit requirement that every structure that implements summary MUST contain a field called IsAnomaly with boolean type.

// GetSummaryKeys implements model.ExperimentMeasurer.GetSummaryKeys.
func (m *Measurer) GetSummaryKeys(measurement *model.Measurement) (interface{}, error) {
return SummaryKeys{IsAnomaly: false}, nil
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Now we implicitly provide the correct always-returning-false implementation when an experiment does not implement the MeasurementSummaryKeysProvider interface. So, we can safely zap the boilerplate code concerning the summary keys for each experiment that always returned false.

@bassosimone bassosimone changed the title Start improving how we set summary keys refactor(all): improve SummaryKeys management Feb 7, 2024
@bassosimone bassosimone marked this pull request as ready for review February 7, 2024 12:48
@bassosimone bassosimone merged commit 0f5529f into master Feb 7, 2024
1 check passed
@bassosimone bassosimone deleted the issue/2654 branch February 7, 2024 13:01
Murphy-OrangeMud pushed a commit to Murphy-OrangeMud/probe-cli that referenced this pull request Feb 13, 2024
While approaching ooni/probe#2667, I
recognized that the approach we're using to generate `SummaryKeys` is
redundant, verbose, and fragile. This diff attempts to improve our
implementation.

We define new types for generating summary keys and
`engine.MeasurementSummaryKeys` to either return the proper summary
keys, if the experiment `TestKeys` support that or return a default
value.

While there, disable the flaky `throttlingWithHTTP` QA check (see
ooni/probe#2668).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant