[BUG]: `actions/labeler` interference with `restricted-paths-guard.yml` workflow

[rwgk]

This note summarizes the investigation into why PR #1965 showed:

• github-actions[bot] added Needs-Restricted-Paths-Review
• then immediately removed Needs-Restricted-Paths-Review
• while also adding cuda.bindings and cuda.core

Bottom line

There is no code path in .github/workflows/restricted-paths-guard.yml that removes Needs-Restricted-Paths-Review.

The workflow still has the intended sticky behavior:

• if review is needed and the label is absent, it adds the label
• if the label is already present, it leaves it in place
• it does not call gh pr edit --remove-label

So the removal appears to be coming from a different label-managing workflow, most likely .github/workflows/pr-auto-label.yml, which uses actions/labeler.

Evidence

1. restricted-paths-guard.yml does not remove the label

The live main copy of .github/workflows/restricted-paths-guard.yml only adds the label or leaves it in place:

• it sets LABEL_ACTION="added" after gh pr edit ... --add-label
• or it sets LABEL_ACTION="left in place (manual removal required)"
• there is no --remove-label anywhere in that workflow

That means the sticky-label behavior was not accidentally removed there.

2. The issue events show add, then remove, then module labels

For PR #1965, GitHub issue events show this exact sequence at 2026-04-22T20:46:11Z:

1. labeled -> Needs-Restricted-Paths-Review
2. unlabeled -> Needs-Restricted-Paths-Review
3. labeled -> cuda.bindings
4. labeled -> cuda.core

All four events were attributed to github-actions[bot].

The ordering matters: the Needs-Restricted-Paths-Review add happened first, and the remove happened immediately afterward in the same second.

3. The workflows running at that exact time were:

• CI: Restricted Paths Guard run 24801785023
• CI: Auto-label PRs by path run 24801785008
• CI: Enforce assignee/label/milestone on PRs run 24801785059

Of those three:

• restricted-paths-guard.yml can add Needs-Restricted-Paths-Review
• pr-metadata-check.yml does not edit labels
• pr-auto-label.yml applies labels using actions/labeler

This leaves pr-auto-label.yml / actions/labeler as the likely source of the removal.

4. pr-auto-label.yml uses actions/labeler

The workflow is:

• file: .github/workflows/pr-auto-label.yml
• action: actions/labeler@634933edcd8ababfe52f92936142cc22ac488b1b (v6.0.1)

Its label rules live in .github/labeler.yml, and for this PR they match:

• cuda.bindings for cuda_bindings/**
• cuda.core for cuda_core/**

That lines up exactly with the labels that were added at the same time the restricted-paths label disappeared.

5. The actions/labeler log says sync-labels: false

The CI: Auto-label PRs by path run log includes:

sync-labels: false

In theory, that setting should mean labeler does not remove labels.

However, there are historical reports/issues against actions/labeler where labels were still removed despite sync-labels: false, or where labels not defined in labeler.yml were still affected.

So the observed behavior is surprising, but not unprecedented.

Current conclusion

My current best explanation is:

1. restricted-paths-guard.yml correctly added Needs-Restricted-Paths-Review
2. pr-auto-label.yml / actions/labeler then removed it while applying the module labels

So this looks like interference from actions/labeler, not a bug in the sticky-label logic inside restricted-paths-guard.yml.

Practical implication

If we want Needs-Restricted-Paths-Review to remain sticky and avoid interference from unrelated label automation, then actions/labeler in .github/workflows/pr-auto-label.yml is the first place I would look to change or replace.

The safest direction would likely be to use an add-only module-labeling step that never removes labels it does not own.

[leofang]

What's puzzling is that the labeler's default for sync-labels is false, so it should not remove any label either. It's likely a race condition but still unclear which workflow has the capability to remove labels.

[leofang]

I think actions/labeler#917 might help. Let's pin our action to a more recent commit...

[rwgk]

Generated with Cursor GPT-5.4 Extra High Fast, from the same agent chat I used to develop restricted-paths-guard.yml

---

One idea: combine .github/workflows/pr-auto-label.yml and .github/workflows/restricted-paths-guard.yml into a single workflow.

Right now we have two separate pull_request_target workflows mutating labels at nearly the same time:

• CI: Auto-label PRs by path
• CI: Restricted Paths Guard

Even if both workflows are individually reasonable, that setup makes it hard to reason about ordering, and it leaves room for cross-workflow races.

If we combine them into one workflow, then we can make the ordering explicit:

1. apply module labels first
2. apply restricted-paths logic second

That way, if the path-labeling step is going to interfere with other labels, the restricted-paths step still runs last and can re-assert Needs-Restricted-Paths-Review.

I see two plausible versions of this:

Option 1: minimal change

• keep using actions/labeler
• move it into the same workflow, before the restricted-paths logic
• use the union of the current triggers (opened, synchronize, reopened, ready_for_review)

This is probably the smallest change and may already be enough to eliminate the race we are seeing.

Option 2: more robust

• stop using actions/labeler
• implement the cuda.bindings / cuda.core / cuda.pathfinder path checks directly in shell
• make that logic add-only, never removing unrelated labels

This adds a bit more code, but it would avoid both cross-workflow races and any actions/labeler-specific label sync behavior.

So my current thought is: combining the workflows seems like a good direction either way. The minimal version is probably worth trying first; the add-only custom labeling version is the cleaner long-term solution if we want fully predictable behavior.

[leofang]

I actually like the unified workflow idea. #1971 only reduces the chance of hitting the race, but not eliminating it. Both Claude and Codex warned me while I was pondering about it.

That said, we should hold off and see if the Runner team figures out the app-based solution... Maybe this would become moot once the other solution is online.