1282838 - Setting rate to 0% serves updates at 100%

Status: RESOLVED FIXED

Description

[Justin Wood (:Callek)]

We had this issue in 47.0.1 where we wanted 0% update rate for 47.0 users.

Setting the rate to 0% is actually serving updates at ~100%.

(I had a potentially similar bug with setting the rate and error reporting via the UI earlier too, but I'll file as a seperate bug just incase its only UI)

Comment 1

[Ben Hearsum (:bhearsum)]

I traced this back, and it looks like it's behaviour that we carried over from AUS2. From https://bugzilla.mozilla.org/show_bug.cgi?id=685862:
(In reply to Ben Hearsum (:bhearsum) from comment #0)
> Currently, AUS3 doesn't pay attention to throttling except for checking for
> non-zero. We need to replicate the AUS2 throttle logic in AUS3. That is:
> - For forced update checks, ignore throttling
> - For background checks:
> -- When throttle=0, ignore the rule
> -- When throttle=100, always consider the rule
> -- When throttle is between 0 and 100, consider the rule that % age of the
> time. Eg, when throttle is 50 the rule should be considered half the time.
> In AUS2, this is implemented with rand().

Rail and I talked about it a bit, and realized that this is very busted. The logic we have right now says "if background rate is 0, and update check is a background check, ignore the rule". This is obviously wrong - we shouldn't ever be ignoring background rate for background checks. These 2 lines of code should probably go:
https://github.com/mozilla/balrog/blob/master/auslib/db.py#L807

I think the existing throttle handling logic will do the rest, but this should be tested more thoroughly with new unit tests.

Comment 2

[Johan Lorenzo [:jlorenzo]]

Created attachment 8784941 [details] [review]
PR

Comment 3

[[github robot]]

Commit pushed to master at https://github.com/mozilla/balrog

https://github.com/mozilla/balrog/commit/18e9f8632f4d9d71cdab81cac490794b30e0ed02
Bug 1282838 - Setting rate to 0% serves updates at 100% (#111). r=bhearsum

Comment 4

[Johan Lorenzo [:jlorenzo]]

See comment 3