Fix backport label handler #2245

apiraino · 2026-01-07T16:46:59Z

Do not allow nominating for backport a PR that is already backport approved.
Revert the -nominated label that was added on GitHub.

r? @Kobzol

thanks

src/handlers/backport.rs

Kobzol

I'm not sure if I understand the change, to be honest 😅 Is it about beta nomination not being triggered when the PR is already stable nominated, and vice versa?

I would expect that if we receive IssuesAction::Labeled { label: FOO }, then pr.labels will already contain FOO. Have you checked whether that's the case or not? 🤔

View changes since this review

src/handlers/backport.rs

apiraino · 2026-01-12T18:11:43Z

I'm not sure if I understand the change, to be honest 😅 Is it about beta nomination not being triggered when the PR is already stable nominated, and vice versa?

I would expect that if we receive IssuesAction::Labeled { label: FOO }, then pr.labels will already contain FOO. Have you checked whether that's the case or not? 🤔

The fix here basically is:

we have a beta-accepted PR
we add stable-nominated
then we add stable-accepted
bug: the backport.rs handler will return without triggering the Zulip notification handler (notify_zulip.rs) because the label check here does not treat beta and stable backport labels separately.

makes sense?

Kobzol · 2026-01-14T07:16:17Z

Ah, makes sense, thanks! I think that in the latest commit you just changed the code so that it will simply ignore all labels? pr_labels needs to be checked.

apiraino · 2026-01-14T11:37:53Z

ah yes you're right, I thought we didn't need it but ofc we do.

Thanks for the review!

Kobzol · 2026-01-14T16:47:31Z

src/handlers/backport.rs

+    if let IssuesAction::Labeled { label } = &event.action
+        && BACKPORT_ACCEPTED_LABELS.contains(&label.name.as_str())
+    {
+        if contains_any(&pr_labels, &BACKPORT_ACCEPTED_LABELS) {


This will have the same bug as before, right? If the PR is already beta-accepted, it will stop the handler here once stable-accepted is added.

You'll need to separate the labels on the axis of beta/stable, rather than nominated/accepted.

Hmm ... you're right but the solution is more complex that separating on another axis. I'm afraid I'll need to map all possible cases (4 labels = 16 cases) and then see if I can reduce to a couple of ifs.

In any case, I want to keep it simple: if this does not work, I have another patch to add "negated labels" when sending zulip notification, that would solve the issue from another point of view.

I'll be back on this.

Can't just remove this:

if contains_any(&pr_labels, &BACKPORT_LABELS) { log::debug!("PR #{} already has a backport label", pr.number); return Ok(None); }

? Seems like the bug is just caused by this.

Btw, I tested that once you receive the Labeled { label: "foo" } event, then pr.labels() already contains foo.

sorry, I am confused by your comment: isn't that chunk of code removed in this patch? Or did you mean to just remove that code without adding anything else?

In the latter case, I think that not checking labels would open up to confusion when adding regression labels (which was the point of this patch).

Yeah, I meant remove without adding anything else. Say that we remove the original check - what will be the problematic situations that could be caused in that case? Adding -nominated once there is already -accepted? Or something else? I don't know what is a "regression label", it wasn't mentioned in this PR so far 😅

apiraino · 2026-01-22T18:07:46Z

ok @Kobzol I've reworked this patch and tried to simplify as much as possible to keep the scope small and clear (I have edited title and commit desc to reflect this).

Now hopefully the logic should be clearer: with this patch I want to avoid that a backport accepted PR be nominated again. If a -nominated label is added, the handler will revert that. As you suggested I am now checking on the naminated/accepted "axis" instead of the beta/stable.

Note: this won't block creating the Zulip backport poll but it can only be handled in the notify_zulip.rs (another patch will follow).

Let me know if now sounds better. Thanks.

Kobzol · 2026-01-23T09:13:09Z

src/handlers/backport.rs

-        return Ok(None);
+
+    // If a "-nominated" label is added to an already "-accepted" PR, remove the label added by github
+    if let IssuesAction::Labeled { label } = &event.action


Just to make sure that it is intended, this logic means that if the PR was e.g. beta accepted previously, it then cannot be also stable nominated.

OK @Kobzol I give up in trying to make this check "smart", I thought I will just hardcode the only two cases I was actually interested in preventing.

wdty?

apiraino · 2026-01-28T16:46:29Z

src/handlers/backport.rs

+            let _ = &event
+                .issue
+                .remove_labels(&ctx.github, label_to_remove)
+                .await
+                .context("failed to remove labels from the issue")
+                .unwrap();


Removing a label after it was added using the GH UI will produce a strange "add label / remove label" events one after the other. This will be solved after we have negated labels rule (as mentioned elsewhere here). That will prevent triggering this handler.

~~(removing the .unwrap())~~

apiraino · 2026-01-28T16:56:02Z

src/handlers/backport.rs

@@ -86,7 +97,7 @@ pub(super) async fn parse_input(
                cfg.required_pr_labels.iter().map(String::as_str).collect();
            if !contains_any(&pr_labels, &required_pr_labels) {


I discovered that this check (contains_any on required_pr_labels) has a little bug: If the triagebot configuration is something like:

required-pr-labels = ["t-libs", "t-libs-api"]

this handler will run twice. This is fixable in different ways (in another patch), I just wanted to leave a note about it.

…proved. Revert the `-nominated` label that was added on GitHub.

Kobzol

I actually wanted to propose this, I think it's the best solution for now 😆

View changes since this review

rustbot assigned Kobzol Jan 7, 2026

apiraino commented Jan 7, 2026

View reviewed changes

src/handlers/backport.rs Outdated Show resolved Hide resolved

apiraino commented Jan 7, 2026

View reviewed changes

src/handlers/backport.rs Show resolved Hide resolved

Kobzol reviewed Jan 9, 2026

View reviewed changes

src/handlers/backport.rs Outdated Show resolved Hide resolved

apiraino force-pushed the fix-backport-handling branch from 265da83 to 502c371 Compare January 12, 2026 16:32

apiraino force-pushed the fix-backport-handling branch 2 times, most recently from 26e7bca to fb54275 Compare January 14, 2026 11:36

Kobzol reviewed Jan 14, 2026

View reviewed changes

apiraino force-pushed the fix-backport-handling branch 2 times, most recently from 66063d5 to 6516a34 Compare January 22, 2026 17:58

apiraino changed the title ~~Fix backport handler~~ Fix backport label handler Jan 22, 2026

apiraino requested a review from Kobzol January 22, 2026 18:07

Kobzol reviewed Jan 23, 2026

View reviewed changes

apiraino force-pushed the fix-backport-handling branch from 6516a34 to b344381 Compare January 28, 2026 15:42

apiraino closed this Jan 28, 2026

apiraino force-pushed the fix-backport-handling branch from b344381 to 6be41b9 Compare January 28, 2026 16:32

apiraino reopened this Jan 28, 2026

apiraino commented Jan 28, 2026

View reviewed changes

Do not allow nominating for backport a PR that is already backport ap…

19f869b

…proved. Revert the `-nominated` label that was added on GitHub.

apiraino force-pushed the fix-backport-handling branch from 73fd160 to 19f869b Compare January 28, 2026 16:57

Kobzol approved these changes Jan 28, 2026

View reviewed changes

		@@ -86,7 +97,7 @@ pub(super) async fn parse_input(
		cfg.required_pr_labels.iter().map(String::as_str).collect();
		if !contains_any(&pr_labels, &required_pr_labels) {

Fix backport label handler #2245

Are you sure you want to change the base?

Fix backport label handler #2245

Uh oh!

Conversation

apiraino commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Kobzol left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

apiraino commented Jan 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kobzol commented Jan 14, 2026

Uh oh!

apiraino commented Jan 14, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apiraino commented Jan 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apiraino Jan 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kobzol left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

apiraino commented Jan 7, 2026 •

edited

Loading

Kobzol left a comment •

edited by rustbot

Loading

apiraino commented Jan 12, 2026 •

edited

Loading

apiraino Jan 28, 2026 •

edited

Loading

Kobzol left a comment •

edited by rustbot

Loading