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

fix: mark signal v0.2.4 as failed #831

Merged
merged 8 commits into from
Mar 25, 2024
Merged

fix: mark signal v0.2.4 as failed #831

merged 8 commits into from
Mar 25, 2024

Conversation

bassosimone
Copy link
Contributor

The ooni/probe-cli#1421 PR trimmed the endpoints and bumped signal's version to v0.2.5.

So we need to ignore versions of signal lower than v0.2.5.

I am wondering whether we should also use a time window because otherwise what happens when we reprocess measurements. If my analysis is correct, then we have an additional issue that there's another check in this codepath that seems to mark signal measurements as failed without any temporal constraints. This would also cause reprocessing to cause downstream issues.

Part of ooni/probe#2636

The ooni/probe-cli#1421 PR trimmed the endpoints and bumped signal's version to v0.2.5.

So we need to ignore versions of signal lower than v0.2.5.

I am wondering whether we should also use a time window because otherwise what happens when we reprocess measurements. If my analysis is correct, then we have an additional issue that there's another check in this codepath that seems to mark signal measurements as failed without any temporal constraints. This would also cause reprocessing to cause downstream issues.

Part of ooni/probe#2636
Copy link

codecov bot commented Mar 22, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (6258173) to head (ff33685).
Report is 1 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff            @@
##            master      #831   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           21        21           
  Lines         1448      1448           
  Branches       116       116           
=========================================
  Hits          1448      1448           
Flag Coverage Δ
ooniauth 100.00% <ø> (ø)
oonirun 100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

bassosimone and others added 4 commits March 22, 2024 12:56
x
I discussed this with @hellais and he said I should not be spending too much time in thinking about reprocessing and recommended to use queries to modify the database.

So, I'll change the todo into a caveat.
Comment on lines 1363 to 1375
if (
parse_version(tv) <= parse_version("0.2.4")
and parse_version(tv) > parse_version("0.2.3")
and start_time >= datetime(2023, 11, 7)
):
# See https://github.com/ooni/probe/issues/2636
# See https://github.com/ooni/probe-cli/pull/1421
scores["accuracy"] = 0.0
return scores

if parse_version(tv) <= parse_version("0.2.3") and start_time >= datetime(
2023, 11, 7
):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see we're using the same start_time for both ifs. I understand the start_time of 2023-11-07 comes from this issue ooni/probe#2627. We noticed that we were testing too many endpoints on 2023-11-28, according to ooni/probe#2636.

I think there are two options here:

Suggested change
if (
parse_version(tv) <= parse_version("0.2.4")
and parse_version(tv) > parse_version("0.2.3")
and start_time >= datetime(2023, 11, 7)
):
# See https://github.com/ooni/probe/issues/2636
# See https://github.com/ooni/probe-cli/pull/1421
scores["accuracy"] = 0.0
return scores
if parse_version(tv) <= parse_version("0.2.3") and start_time >= datetime(
2023, 11, 7
):
if (
parse_version(tv) <= parse_version("0.2.4")
and start_time >= datetime(2023, 11, 7)
):
# See https://github.com/ooni/probe/issues/2636
# See https://github.com/ooni/probe-cli/pull/1421
  1. Or using 2023-11-28 as the cutoff date for the fist check and dropping the and parse_version(tv) > parse_version("0.2.3") line.

The former suggestion coalesces two cases that are related together. The second one keeps them separate but applies the same kind of checking patterns to the code.

Copy link
Member

Choose a reason for hiding this comment

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

As discussed on slack it's probably better to be explicit and not collapse the two cases into one, so that it's more clear they are addressing specific different issues affecting different measurements.

Copy link
Contributor Author

@bassosimone bassosimone left a comment

Choose a reason for hiding this comment

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

LGTM with an optional diff to further simplify the logic.

Comment on lines 1363 to 1365
if parse_version(tv) <= parse_version("0.2.4") and parse_version(
tv
) > parse_version("0.2.3"):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Suggested change
if parse_version(tv) <= parse_version("0.2.4") and parse_version(
tv
) > parse_version("0.2.3"):
if parse_version(tv) == parse_version("0.2.4"):

IIUC, we are saying that we're not sure about version 0.2.4 and we can just safely drop it, right? Then, in such a case, I suggest it's better to just check for equality here.

@hellais hellais merged commit b5fa026 into master Mar 25, 2024
6 checks passed
@hellais hellais deleted the issue/2636 branch March 25, 2024 13:49
hellais added a commit that referenced this pull request Apr 24, 2024
* The integration test was using as a fixture measurement from
  before the incident
(https://explorer.ooni.org/m/20210427000432.751743_AU_signal_490428d8ebc76e6b),
but was expecting it to be marked as failed
* The unit test was using a measurement that was from a newer version of
  probe
(https://explorer.ooni.org/measurement/20221118T104419Z_signal_IT_30722_n1_Q02UUAiiHlVU0VE6),
which should not be marked as failed either

As part of #831 we improved the
logic for scoring to be more precise and so these checks were now
failing.

We now use in both cases a correct "bad case" and in the unit test we
also include the previous case as a "good case".
hellais added a commit that referenced this pull request Apr 24, 2024
* Add correct fixture for bug 2627

* Correct the fixtures for scoring of bug 2627

* The integration test was using as a fixture measurement from
  before the incident
(https://explorer.ooni.org/m/20210427000432.751743_AU_signal_490428d8ebc76e6b),
but was expecting it to be marked as failed
* The unit test was using a measurement that was from a newer version of
  probe
(https://explorer.ooni.org/measurement/20221118T104419Z_signal_IT_30722_n1_Q02UUAiiHlVU0VE6),
which should not be marked as failed either

As part of #831 we improved the
logic for scoring to be more precise and so these checks were now
failing.

We now use in both cases a correct "bad case" and in the unit test we
also include the previous case as a "good case".

* Apply path filters to fastpath and legacy API tests

* Add clickhouse-driver to requirement.txt
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