Repository navigation
unassign-inactive-assignees never detects linked PRs, so assignees with open PRs get unassigned #30092
Description
What happened?
It looks like unassign-inactive-assignees never recognizes a linked PR, so contributors with an open, ready PR are getting unassigned after 7 days anyway.
First, thank you for all the work getting this workflow running again (#29298, #29326, #29609, #29770). It's been running cleanly since Oct 17, which is how I noticed this.
What the workflow is for: per the file header, it frees up "help wanted" issues whose assignee has no non draft PR (open and ready, or merged) linked within 7 days.
Current behavior:
- The workflow loads the issue timeline and looks at
cross-referencedevents. - Line 184 skips any event where
event.source.type !== 'pull_request'. - As far as I can tell, the REST timeline API reports cross referenced PRs as
source.type: "issue", withsource.issue.pull_requestset instead. - So every event is skipped, and the readiness check (
pulls.get, thenisReady) never runs. linkedPRAuthorSetstays empty, and every non privileged assignee past 7 days is removed, even with an open, ready PR that closes the issue.
Minimal repro:
gh api repos/google-gemini/gemini-cli/issues/28052/timeline --paginate \
--jq '.[]|select(.event=="cross-referenced")|{t:.source.type, pr:(.source.issue.pull_request!=null), n:.source.issue.number}'Every PR (28054, 28069, 28200, ...) comes back as "t": "issue", "pr": true.
The run logs seem to agree: the PR ... state= line never prints in runs 41291334509, 41186944793, 41030516312, 40478041559 or 39019643178. A couple of examples:
- Run 41030516312 (Oct 30) unassigned the assignee on fix(cli): all Executing subagent tool calls dropped from UI state, breaking task-tree hierarchy #22589, while fix(cli): show executing subagent tool calls in the task tree #29859 (open, not a draft, closes fix(cli): all Executing subagent tool calls dropped from UI state, breaking task-tree hierarchy #22589) had been open since Oct 21.
- Run 39019643178 (Oct 17) unassigned people on feat(core): add allowCommandSubstitution toggle in settings #27400, fix(cli): include all Executing subagent tool calls in useToolScheduler state #22590, feat(routing): Add configurable numeric routing rules (fixes #21805) #27406, fix(core): cap search results and clarify context overflow message #19638 and feat(cli): support skill activation via /skill-name in non-interactive mode #29546, which all had open non draft PRs.
Where the PR check stops today:
flowchart TD
A[cross-referenced event] --> B{source.type === 'pull_request'?}
B -- "no (API sends 'issue')" --> X[skip event]
B -- yes --> C[pulls.get]
C --> D{isReady?}
D -- yes --> E[keep assignee]
D -- no --> F[may unassign]
X --> F
Suggested fix (one line):
- event.source.type !== 'pull_request' ||
+ !event.source.issue?.pull_request ||I also noticed #28798 was closed on Oct 28 on the idea that open PRs keep assignments indefinitely. From the logs it seems to be the reverse right now, so it might be worth a second look once this is sorted.
What did you expect to happen?
An assignee with an open, non draft PR linked to the issue (or a merged one) should stay assigned, as the file header describes. The PR ... state= log line should show up for each linked PR.
Client information
Client Information
Not applicable, this is the .github/workflows/unassign-inactive-assignees.yml GitHub Actions workflow on main (6814e00).
Login information
Not applicable.
Anything else we need to know?
One question I wasn't sure about: which policy would you prefer here? The smallest fix above counts any cross referencing non draft PR. A stricter option would be to only count PRs that actually close the issue (closingIssuesReferences via GraphQL), so a passing mention can't keep an assignment alive. Happy to open a PR for whichever you think fits best, and of course I may be missing some context.
Activity
yuvrajangadsingh commentedon Nov 2, 2026
another real case from today: the bot unassigned me from #29945 even though #29977 (open, not a draft,
Fixes #29945) has been up since Oct 27.the #29945 timeline shows both linked PRs (#29948 and #29977) as
source.type: "issue"withsource.issue.pull_requestset, same as your repro.ANUBprad commentedon Nov 2, 2026
Hi! I'd like to work on this issue as a community contribution.
I've inspected
.github/workflows/unassign-inactive-assignees.ymland the reportedsource.typemismatch appears to be the root cause. I can work on a focused fix to correctly identify cross-referenced PRs, along with validation for open, draft, and merged PR cases.Could a maintainer confirm the intended handling and mark this
help wantedif it's suitable for community contribution?abhiramshaji-cyber commentedon Nov 2, 2026
Hey @yuvrajangadsingh, thanks so much for adding this, and sorry the bot caught you too. I checked the #29945 timeline and it lines up exactly: #29948 and #29977 both show up as
source.type: "issue"withsource.issue.pull_requestset, and #29977 is yours, open and not a draft. So it looks like the same root cause, and a really helpful second data point.Hi @ANUBprad, thank you for offering to pick this up, that's really kind! In case it saves you some digging: the filter is in the
cross-referencedloop in.github/workflows/unassign-inactive-assignees.yml, around lines 180 to 189 on current main, wherelinkedPRAuthorSetgets filled. The #29945 timeline might be handy for checking the fix, since it has two real PRs plus a cross reference from this issue (pull_requestnot set) that should still be skipped.I'm very happy for you to take it, I'll just leave the call to the maintainers. The open question from the original post still stands too: should any linked non draft PR count, or only PRs that actually close the issue (
closingIssuesReferences)? I'd love to hear what everyone thinks.abhiramshaji-cyber commentedon Nov 7, 2026
Hi maintainers, hope you're doing well! I know the triage queue is busy right now, so no rush at all. Would a small reproduction or any more detail from the timelines help here? Whenever someone gets a chance, it'd be great to know whether @ANUBprad is good to go ahead, and whether any linked non draft PR should count or only ones that close the issue.