utils.get_checked_versions() returns an empty dict in three cases:
- It's merge day
- The branch versions aren't consecutive
- Bugzilla's nightly ≠ product-details' nightly
Every rule that calls init_versions() inherits this as a gate. When it returns {}, has_enough_data() is False then the rule logs "hasn't enough data to run" and does nothing.
Roughly 15 rules depend on this (all call init_versions()):
missed_uplifts, regression_set_status_flags, telemetry_expiry_tracking_autoapproval, ni_from_manager, unlanded, topcrash_highlight, missing_beta_status, tracking, tracked_needinfo, security_affected_versions, nightly_reopened, uplift_beta, regression_new_set_nightly_affected, tracked_attention.
The impact is a multi-day coverage gap around every merge, not just a single merge-day skip. The rule bails on merge day itself, and then keeps bailing for a day or two afterward while product-details catches up — e.g. observed release 153 / beta 153 / nightly 155, which fails the "consecutive versions" check even though it wasn't merge day. Every dependent rule is dark for that whole window.
Flow, for reference:
- rule init → init_versions() → utils.get_checked_versions() returns {}
- has_enough_data() is then False, so send_email() logs "hasn't enough data to run" and returns.
Suggestion:
Rather than bailing when the branch numbers look inconsistent, could we maybe use nightly as the source of truth in this scenario?
Nightly is typically updated first in product-details after a merge, so it could be a reliable anchor during the window when the other branches are still stale or non-consecutive?
utils.get_checked_versions() returns an empty dict in three cases:
Every rule that calls init_versions() inherits this as a gate. When it returns {}, has_enough_data() is False then the rule logs "hasn't enough data to run" and does nothing.
Roughly 15 rules depend on this (all call init_versions()):
missed_uplifts, regression_set_status_flags, telemetry_expiry_tracking_autoapproval, ni_from_manager, unlanded, topcrash_highlight, missing_beta_status, tracking, tracked_needinfo, security_affected_versions, nightly_reopened, uplift_beta, regression_new_set_nightly_affected, tracked_attention.
The impact is a multi-day coverage gap around every merge, not just a single merge-day skip. The rule bails on merge day itself, and then keeps bailing for a day or two afterward while product-details catches up — e.g. observed release 153 / beta 153 / nightly 155, which fails the "consecutive versions" check even though it wasn't merge day. Every dependent rule is dark for that whole window.
Flow, for reference:
Suggestion:
Rather than bailing when the branch numbers look inconsistent, could we maybe use nightly as the source of truth in this scenario?
Nightly is typically updated first in product-details after a merge, so it could be a reliable anchor during the window when the other branches are still stale or non-consecutive?