Skip to content

unassign-inactive-assignees treats any open PR as progress, so stale assignments never expire #28798

Description

@chiruu12

What happened?

.github/workflows/unassign-inactive-assignees.yml unassigns a help wanted assignee after 7 days if they have no qualifying linked PR. The qualifying check is:

const isReady = (pr.state === 'open' && !pr.draft) ||
                (pr.state === 'closed' && pr.merged_at !== null);

It looks at state, draft and merged. It never looks at pr.updated_at. So one non-draft PR keeps an assignment alive forever, no matter how long that PR has been dead.

That is what is happening to the label right now. Every one of these assignments is being held open by a PR that has not been touched in two to three months:

Issue Assignee Holding PR PR last updated
#22784 manas-raj999 #25378 2026-06-02
#22589 TravisHaa #22590 2026-06-02
#21805 ujjwalv01 #27406 2026-06-02
#18087 KoushikAD1234 #27415 2026-06-02
#21691 ProthamD #27463 2026-06-09
#22274 anishs1207 #27588 2026-06-02

There are 29 open help wanted issues. 28 have an assignee. The only unassigned one is #4191, the public roadmap tracker. For a label whose purpose is to route work to outside contributors, there is currently nothing on it to pick up.

Second gap in the same check. The PR is fetched from whichever repo the cross-reference came from:

const { data: pr } = await github.rest.pulls.get({
  owner: prOwner, repo: prRepo, pull_number: prNumber,
});

There is no check that prOwner/prRepo is this repository. A non-draft PR opened inside someone's own fork, referencing an upstream issue, satisfies the check. #22274 already has a HaleTom/gemini-cli#1 cross-reference sitting in its timeline. That one is a draft so it does not fire, but nothing stops the non-draft version.

What did you expect to happen?

An assignment held by a PR that has been silent for months should expire, so the issue returns to the pool.

Suggestions, and I am happy to send a PR for whichever direction you prefer:

  1. Add a freshness requirement to isReady, for example the PR must have been updated within the last 30 days. Keep the existing 7 day rule for the case where no PR exists at all.
  2. Before unassigning on the stale-PR path, have the workflow post one comment on the issue asking the assignee to confirm they are still on it, and only unassign if there is no reply after another 7 days. That avoids pulling an issue out from under someone who is mid-rebase.
  3. Require the linked PR to live in this repository, not in a fork's own repo.

Note on exemptions: the workflow already skips maintainers, org members and anyone with triage or above via isPrivilegedUser, and that logic does not need to change. This only affects outside contributors, which is the group the grace period was written for in the first place.

Client information

Not applicable. This is a repository automation issue, not a CLI issue.

Anything else we need to know?

Numbers above were read from the API on 2026-08-13 and will drift.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/platformIssues related to Build infra, Release mgmt, Testing, Eval infra, Capacity, Quota mgmtstatus/need-triageIssues that need to be triaged by the triage automation.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions