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

Don't flag add-ons for growth threshold if hotness is negative #23031

Merged
merged 2 commits into from
Jan 30, 2025

Conversation

diox
Copy link
Member

@diox diox commented Jan 27, 2025

@diox diox requested review from a team and KevinMind and removed request for a team January 27, 2025 16:51
@KevinMind
Copy link
Contributor

@diox code looks good. Could you add a test section so I can verify locally. Feel free to include a db zip of the initial state if that is easier than setup instructions.

@diox
Copy link
Member Author

diox commented Jan 29, 2025

It's super painful to test locally because there is quite a bit of set up to do. Since the included unit tests replicate that setup I only relied on unit tests while writing this patch myself.

@diox diox requested a review from KevinMind January 29, 2025 12:34
@KevinMind
Copy link
Contributor

It's super painful to test locally because there is quite a bit of set up to do. Since the included unit tests replicate that setup I only relied on unit tests while writing this patch myself.

I'm not a fan of that response, but I understand if it's difficult. Question, assuming after merging this went straight to production, what would be the cost if there was a bug and it was totally wrong.

How often is the "flagging" that is happening, happening?

@diox
Copy link
Member Author

diox commented Jan 29, 2025

To be clear, it is possible to test this by careful crafting data ; that's how I did it last time locally (described in #22875) and on dev/stage, and that's how I plan to test that with QA on dev/stage. It's just very time consuming and fiddly because it depends on the average hotness value of all your add-ons in a given tier (setting up the unit tests correctly already took way longer than writing the patch itself). You have to:

  • Set up a tier with specific lower_adu_threshold, upper_adu_threshold, and a growth_threshold_before_flagging value
  • Set up some add-ons, auto_approve them so they are signed, and forcing their average_daily_users value to be in that tier, and hotness values to what you want to test
  • Trigger the task and check NeedsHumanReview instances were created on add-ons with hotness over average + threshold (and, in this case, force that value for a tier to be negative and check the results)

If QA verification on dev or stage finds a bug then we'll revert or fix as usual.

The task is triggered once a day after we have computed the hotness value for each add-on for the day.

Copy link
Contributor

@KevinMind KevinMind left a comment

Choose a reason for hiding this comment

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

Didn't verify 🚢 🙈

@diox diox merged commit ad4569b into mozilla:master Jan 30, 2025
49 checks passed
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.

[Task] Don't flag add-ons for growth threshold if hotness is negative
2 participants