Repository navigation
Unable to assign issues to myself via --add-assignee @me or --add-assignee USERNAME #6235
Description
Activity
Hi, thank you for reporting. GitHub CLI resolves your username to an assignee ID by doing a lookup in the context of "assignable users". I was able to pull down the list of assignable users for this repository, which is massive, and indeed your username isn't among them:
# warning: slow gh api graphql -f query='query($endCursor:String){repository(owner:"azure",name:"enterprise-scale"){assignableUsers(first:100,after:$endCursor){nodes{login}pageInfo{endCursor,hasNextPage}}}}' --paginate --jq '.data.repository.assignableUsers.nodes[].login' | tee assignable-azure.txt
I think resolving usernames through
assignableUsersis only viable for smaller orgs, but not for orgs of the size ofAzure. I think GitHub CLI should switch to resolving a username directly, rather than trying to look it up in a large preloaded collection, which is also slow.Ref. #4876
I suppose this issue has already been solved. It seems that version with the head of branch
trunkworks perfectly fine now withgh issue edit --add-assignee @me@Shion1305 Not exactly. This feature works properly for small organizations but still does not work for large ones with many
assignableUsers. We have a WIP PR to address this issue though.Reacted by Alexander Sehr+1
@samcoe - Any updates on the WIP PR. We are also experiencing this issue with our issue automation on Azure/bicep-registry-modules
Reacted by Rainer HalanekAlso +1 this. Happened to me in the bicep-registry-modules project that @ChrisSidebotham posted above.
+1, also Bicep registry repo
- added a commit that references this issue
on Mar 2, 2024 - added a commit that references this issue
on Mar 12, 2024 1 remaining item
Opened GH Support ticket to track this also
@ChrisSidebotham : Let me catch you up but the short of it is that
mislavno longer works at GitHub, so any time he can spare from supporting other OSS projects is welcome but don't expect it.- As you can see in issue edit: avoid race conditions when editing assignees, reviewers #4876, this involves reworking the underpinnings of how assignees for issues and PRs are handled.
- The team is open to PRs from the community given our current understaffed situation.
Is this something you might be able to contribute?
Hi @andyfeller - I could try look or find someone with a suitable skillset, @jtracey93 for awareness.
@ChrisSidebotham If no one on your side is assigned to it, I'm willing to work on it. I had a look, and a lot can be reused from
mislav's #4876
I think editable_http.go might be better suited in https://github.com/cli/cli/tree/trunk/api but that's for another issue/PRReacted by ChrisSidebotham-MSFT@wingleung - If you can contribute that would be great - we are struggling to find availability currently
Reacted by Wing@Shion1305 Not exactly. This feature works properly for small organisations but still does not work for large ones with many
assignableUsers. We have a WIP PR to address this issue though.@samcoe I revived
mislav's old PR and updated it to the current version, unfortunately I don't have an organisation as big as the azure one 😅 is this something that can be tested on github's side or by @jtracey93 ?I think this PR could already be tested for this ticket.
but the functionality requested in #4844 should probably be a follow up to supportnvm, added a commit for that 👉 #4844 (comment)team_reviewers@Shion1305 Not exactly. This feature works properly for small organisations but still does not work for large ones with many
assignableUsers. We have a WIP PR to address this issue though.@samcoe I revived
mislav's old PR and updated it to the current version, unfortunately I don't have an organisation as big as the azure one 😅 is this something that can be tested on github's side or by @jtracey93 ?I think this PR could already be tested for this ticket.
but the functionality requested in #4844 should probably be a follow up to supportnvm, added a commit for that 👉 #4844 (comment)team_reviewersI can always test where needed!
Reacted by Andy Feller and Wing@ChrisSidebotham great! 🙏 the test case before merge would be:
- checkout the PR:
gh pr checkout https://github.com/cli/cli/pull/9037 - build the cli, it will be in the
bin/folder (more info)- Unix-like systems:
make - Windows:
go run script/build.go
- Unix-like systems:
- run @jtracey93 's steps to reproduce from his original post, but instead of
gh issue edit ...the command should point to your cli buildPATH_TO_YOUR_CLI issue edit ...- where
PATH_TO_YOUR_CLIis the path to your newly built cli binary, for example../cli/bin/gh issue edit ...
- where
- checkout the PR:
I think I have an assumption, @jtracey93 is it possible that you need to be added to the microsoft/azure organisation in github? when I do a query with
jtracey93to see if anything comes back from theassignableUsers, I still don't get any results.
whereas a query with your other colleagueSpringstonedoes return his node- 🚫
gh api graphql -f query='query { repository(owner: "Azure", name: "Enterprise-Scale") { assignableUsers(query: "jtracey93", first: 1) { nodes { login } } } }' - ✅
gh api graphql -f query='query { repository(owner: "Azure", name: "Enterprise-Scale") { assignableUsers(query: "Springstone", first: 1) { nodes { login } } } }'
if that's not it, I think we need to add admins to the
assignableUsersas well, which is something that needs to change in the github api- 🚫
Azure/bicep-registry-modules#1906 @wingleung - This looks to have resolved our pagination problem against the assignable users?
@ChrisSidebotham thank you for testing!
The tool does pagination to get all the assignable users 👉 https://github.com/cli/cli/blob/trunk/api/queries_repo.go#L1107-L1119. This is a slow query but it doesn't mean it's the core cause of this bug.
The repo you tested on (
Azure/bicep-registry-modules) is different from the one thatjtracey93mentioned (Azure/Enterprise-Scale)Azure/bicep-registry-modules: has 49 assignable users which includesjtracey93andChrisSidebotham
👉gh api graphql -f query='query($endCursor:String){repository(owner:"azure",name:"bicep-registry-modules"){assignableUsers(first:100,after:$endCursor){nodes{login}pageInfo{endCursor,hasNextPage}}}}' --paginate --jq '.data.repository.assignableUsers.nodes[].login' | tee assignable-azure-bicep.txtAzure/Enterprise-Scale: has 1611 assignable users which doesn't includejtracey93orChrisSidebotham
👉gh api graphql -f query='query($endCursor:String){repository(owner:"azure",name:"enterprise-scale"){assignableUsers(first:100,after:$endCursor){nodes{login}pageInfo{endCursor,hasNextPage}}}}' --paginate --jq '.data.repository.assignableUsers.nodes[].login' | tee assignable-azure.txt
As mentioned in #6235 (comment) the user just isn't defined in the assignable user list. So the question is why certain users are not included in the assignable users list, maybe there is something missing or overwriting in the syncing between the azure organisation and github? I don't have access to the internals of github's graphql, so if the issue is not resolved I think we'll need someone from github to take a further look at this from the internal side @andyfeller.
To be sure about the fix, I think we should explore some more test cases if you (or your team) can make some time 😄 🙏
Test case: reproducible error
- using the old cli
- try and add
jtracey93or yourself to an issue onAzure/Enterprise-Scale
👉gh issue edit https://github.com/Azure/Enterprise-Scale/issues/1035 --add-assignee 'jtracey93' - assert result is a
'jtracey93' not founderror
Test case: fix
- using this PR build
- try and add
jtracey93or yourself to an issue onAzure/Enterprise-Scale
👉../cli/bin/gh issue edit https://github.com/Azure/Enterprise-Scale/issues/1035 --add-assignee 'jtracey93' - assert no error was thrown and
jtracey93was added as assignee
Test case: same flow but in interactive mode
- using this PR build
- try and add
jtracey93or yourself to an issue onAzure/Enterprise-Scale
👉../cli/bin/gh issue edit https://github.com/Azure/Enterprise-Scale/issues/1035
👉 chooseAssigneesand use the autocomplete to type and choosejtracey93 - assert no error was thrown and
jtracey93was added as assignee
Opened GH Support ticket to track this also
It's possible I'm missing some information because I don't have insights into that ticket
With a recent version of gh (
gh version 2.89.0 (2026-03-26)), I see the following:$ gh pr edit --add-reviewer @me GraphQL: Could not resolve user with login '@me'. (requestReviewsByLogin)Although it does have a different root cause than a large organization (this is in a small org), it is covered by the original description of this issue.
👋 @forivall, I think that is a different problem than this issue. I actually think this issue is fixed now with some rewrites we've done to the command recently.
Could I trouble you to open a new issue for what you are describing please?
Reacted by Emily Marigold Klassen- added a commit that references this issue
on Aug 6, 2026
Describe the bug
Unable to assign issues to myself via
--add-assignee @meor--add-assignee USERNAMEgh version 2.15.0 (2022-09-06)
Steps to reproduce the behavior
gh issue edit https://github.com/Azure/Enterprise-Scale/issues/1035 --add-assignee '@me''jtracey93' not foundgh issue edit https://github.com/Azure/Enterprise-Scale/issues/1035 --add-assignee 'jtracey93''jtracey93' not foundgh issue edit https://github.com/Azure/Enterprise-Scale/issues/1035 --add-assignee 'anotherUserNameThatsNotMe'Expected vs actual behavior
Able to assign issues to myself via gh cli