From 329a28feb88c8c589815c848d0fcd161229dbc7e Mon Sep 17 00:00:00 2001 From: Jared Wein Date: Mon, 17 Aug 2026 16:20:41 -0400 Subject: [PATCH 1/3] Send Android Toolbar and Homepage and IP Protection bugs for automatic triage, now that all three have channels Three pairs join `TRIAGED_COMPONENTS`. `get_bz_params` loops the tuple to build one AND group per pair, so the query needs no change: I ran the generated chart against BMO over 90 days and got 263 open defects against the eight pairs, up from 178, split 35 Homepage, 32 IP Protection and 18 Toolbar. No cross pairing appeared, and none can -- BMO has no `Firefox :: Homepage` and no `Firefox :: Toolbar` (the desktop component is `Toolbars and Customization`), and `IP Protection` exists only under `Firefox`. The AND groups are what keep that true if somebody creates one. `max_triggers` stays at 3. Staff-filed volume goes from about 120 to 168 per 90 days, which is 1.87/day against the 72/day an hourly run with a cap of 3 allows; four filings in these components inside one hour is a ~10^-6 event, and a burst drains over successive runs inside the 24-hour `days_lookup` window with `left_for_next_run` reporting the backlog. What actually changes is spend, roughly 40 agent runs a month to 56. The cap also bounds how many unreviewed Bugzilla comments a bad prompt change can produce in an hour, and three components are about to start posting unattended, so leaving it at 3 is the positive choice rather than the absence of a reason to raise it. Requires the matching bugbug changes to be deployed first. The comment above `TRIAGED_COMPONENTS` now says so, since until now that constraint lived only in commit messages: `channel_for` fails closed on a component missing from the agent's `TRIAGE_SCOPE`, which silences the notification but not the run, so the analysis and the severity change land with nobody told. Nothing checks the two lists agree and nothing can -- they are in separate repos. Because scripts/cron_common_start.sh checks out `releases/latest`, this commit is inert on master; the release cut is the switch, so the gate is "agent rolled out before the release", not merge order. No test changes; the 27 tests derive from `TRIAGED_COMPONENTS` and pass unchanged. I could not run `--dryrun`, since it needs the gitignored `configs/people.json`. --- bugbot/rules/frontend_triage.py | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/bugbot/rules/frontend_triage.py b/bugbot/rules/frontend_triage.py index 518f083a4..fbcb816da 100644 --- a/bugbot/rules/frontend_triage.py +++ b/bugbot/rules/frontend_triage.py @@ -12,12 +12,22 @@ # The components the agent triages, as `(product, component)` pairs. Kept here rather # than in configs/rules.json on purpose: the agent's analysis lands on the bug # unattended, so widening its reach should take a code review. +# +# Every pair here needs a channel in the agent's own `TRIAGE_SCOPE` (bugbug's +# agents/frontend-triage/hackbot_agents/frontend_triage/config.py), and the agent has to +# be deployed with it first. `channel_for` fails closed, which silences the Slack +# notification but not the run: the comment and the severity change still apply, so a +# pair added here ahead of the agent gets unattended triage with nobody told. Nothing +# checks this -- the two lists are in separate repos and cannot see each other. TRIAGED_COMPONENTS = ( ("Firefox", "New Tab Page"), ("Firefox for Android", "History"), ("Toolkit", "Application Update"), ("Firefox", "Installer"), ("Firefox", "Site Permissions"), + ("Firefox", "IP Protection"), + ("Firefox for Android", "Toolbar"), + ("Firefox for Android", "Homepage"), ) From 4aa656e6c49a2fe797857b31a0ee248e1967db95 Mon Sep 17 00:00:00 2001 From: Jared Wein Date: Mon, 17 Aug 2026 17:01:58 -0400 Subject: [PATCH 2/3] Send Firefox :: Sharing bugs for automatic triage now that the agent has a channel and knows the share sheet is in widget/ One pair joins `TRIAGED_COMPONENTS`. Volume is high for a component this narrow: 38 open defects filed in the last 90 days, 34 of them by staff, against 22 for IP Protection and 90 for New Tab Page. `max_triggers` stays at 3. Staff-filed volume across the nine pairs goes to about 202 per 90 days, or 2.24/day, against the 72/day an hourly run with a cap of 3 allows. The cap still only binds on four filings in these components inside one hour, and `left_for_next_run` reports the backlog when it does. Requires the matching hackbot change to be deployed first, and `#content-sharing-automation` to exist and be public before that. `channel_for` fails closed, so a missing entry or a wrong channel name silences the notification but not the run. No test changes; the 27 tests derive from `TRIAGED_COMPONENTS`. --- bugbot/rules/frontend_triage.py | 1 + 1 file changed, 1 insertion(+) diff --git a/bugbot/rules/frontend_triage.py b/bugbot/rules/frontend_triage.py index fbcb816da..36e56b150 100644 --- a/bugbot/rules/frontend_triage.py +++ b/bugbot/rules/frontend_triage.py @@ -25,6 +25,7 @@ ("Toolkit", "Application Update"), ("Firefox", "Installer"), ("Firefox", "Site Permissions"), + ("Firefox", "Sharing"), ("Firefox", "IP Protection"), ("Firefox for Android", "Toolbar"), ("Firefox for Android", "Homepage"), From 87cc57623448d6aacd1a93f7d9eb611fe10ad0e5 Mon Sep 17 00:00:00 2001 From: Jared Wein Date: Mon, 17 Aug 2026 17:04:26 -0400 Subject: [PATCH 3/3] Raise the frontend-triage trigger cap to 5 per run so a burst of filings drains in fewer hours `max_triggers` is a per-run cap and the rule runs hourly, so this raises the ceiling from 72 to 120 runs a day against staff-filed demand of roughly 2.24/day across the nine components now in scope. Steady state is unaffected -- the cap has never bound at that rate. What changes is how fast a burst clears: ten bugs from one QA session drained over four hourly runs at 3 and clears in two at 5, and each run held back was reported in the email as `left_for_next_run` rather than lost. The cost is the other thing this cap bounds. It is also the limit on how many unreviewed Bugzilla comments a bad prompt or ruleset change can produce in one hour before anyone notices, so that worst case goes from 3 to 5. No test change: both cap tests set `max_triggers` explicitly rather than reading the config, and 27 pass. --- configs/rules.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/rules.json b/configs/rules.json index 530fda93f..630e561dd 100644 --- a/configs/rules.json +++ b/configs/rules.json @@ -422,7 +422,7 @@ "frontend_triage": { "days_lookup": 1, "max_days_in_cache": 30, - "max_triggers": 3 + "max_triggers": 5 }, "performancebug": { "max_days_in_cache": 7,