gh pr [comment] not working correctly for few days

Describe the bug

For few days (~10, potentially related to 2.44.1?) I have strange behaviors with the gh pr [comment] command.

Because it's attached to a private project, I can't share complete example, but I had two issues:

gh pr comment -b "rfm" done from a repository branch sent the comment rfm to a completely different PR, totally unrelated to my branch
gh pr comment -b "rfm" refused to create a comment with the message no pull requests found for branch "main". However, the pr has been created using gh pr create ….

The problem is this is not for all branches, all PRs… so I can't provide a clear reproducer.

I had to transform my command into gh pr comment (git rev-parse --abbrev-ref HEAD) -b "rfm" to make it work.

Expected vs actual behavior

Expected behavior is for gh pr to resolve the PR like it was the case in the past.

Logs

For the second case, the only log I have is no pull requests found for branch "main".

Please, ask for test if you want more details, because I can't share links to private registries, even if it's on GitHub.com.

@davinkevin

Hey @davinkevin, thanks for opening this issue and sorry for the trouble, that sounds very annoying. What you're describing is very strange and I can't think of any change that has gone in recently that would impact the pr comment command.

It would be extremely useful if you could catch one of these in the wild with GH_DEBUG=api turned on (and redacting any proprietary information from the output).

Is there anything else you might have changed about your workflow recently? If you go back to release 2.43.1 for a bit I wonder if you'd still experience this.

Find attached the output of the command gh pr comment -b rfm.

[git remote -v]
[git config --get-regexp ^remote\..*\.gh-resolved$]
[git symbolic-ref --quiet HEAD]
[git config --get-regexp ^branch\.kdavin/32685-database-tasks-resources-are-adjusted-to-avoid-CPUThrottling-and-memory-overprovionning-\.(remote|merge)$]
[git remote -v]
[git config --get-regexp ^remote\..*\.gh-resolved$]
⣾* Request at 2024-02-26 15:54:57.07401 +0100 CET m=+0.118745209
* Request to https://api.github.com/graphql
> POST /graphql HTTP/1.1
> Host: api.github.com
> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
> Authorization: token ████████████████████
> Content-Length: 560
> Content-Type: application/json; charset=utf-8
> Graphql-Features: merge_queue
> Time-Zone: Europe/Paris
> User-Agent: GitHub CLI 2.44.1

GraphQL query:
query PullRequestForBranch($owner: String!, $repo: String!, $headRefName: String!, $states: [PullRequestState!]) {
    repository(owner: $owner, name: $repo) {
      pullRequests(headRefName: $headRefName, states: $states, first: 30, orderBy: { field: CREATED_AT, direction: DESC }) {
        nodes {id,url,number,state,baseRefName,headRefName,isCrossRepository,headRepositoryOwner{id,login,...on User{name}}}
      }
      defaultBranchRef { name }
    }
  }
GraphQL variables: {"headRefName":"main","owner":"FOO","repo":"BAR","states":null}

⢿< HTTP/2.0 200 OK
< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
< Content-Security-Policy: default-src 'none'
< Content-Type: application/json; charset=utf-8
< Date: Mon, 26 Feb 2024 14:54:57 GMT
< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
< Server: GitHub.com
< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
< Vary: Accept-Encoding, Accept, X-Requested-With
< X-Accepted-Oauth-Scopes: repo
< X-Content-Type-Options: nosniff
< X-Frame-Options: deny
< X-Github-Media-Type: github.merge-info-preview; param=nebula-preview; format=json
< X-Github-Request-Id: EC85:0F6C:329BEEF:334101A:65DCA641
< X-Oauth-Client-Id: 178c6fc778ccc68e1d6a
< X-Oauth-Scopes: gist, project, read:org, repo
< X-Ratelimit-Limit: 5000
< X-Ratelimit-Remaining: 4982
< X-Ratelimit-Reset: 1708959643
< X-Ratelimit-Resource: graphql
< X-Ratelimit-Used: 18
< X-Xss-Protection: 0

{
  "data": {
    "repository": {
      "pullRequests": {
        "nodes": [
          {
            "id": "PR_kwDOAnM6XM5N0mPL",
            "url": "https://github.com/FOO/BAR/pull/22123",
            "number": 22123,
            "state": "CLOSED",
            "baseRefName": "ABC-team/new-DFG",
            "headRefName": "main",
            "isCrossRepository": false,
            "headRepositoryOwner": {
              "id": "…",
              "login": "…"
            }
          }
        ]
      },
      "defaultBranchRef": {
        "name": "main"
      }
    }
  }
}

* Request took 353.955667ms
no pull requests found for branch "main"

I've redacted data, but I tried to keep the same value for every redacted data.

FYI, the one not selected in this PR is totally unrelated to my work (PR_kwDOAnM6XM5N0mPL) 😅.

And it's not better with the previous version:

And I didn't change anything in my workflow recently. The strange part is this is not all the time the same problem. It may work for one branch, not work at all on another one… or just select the wrong branch and push comment to the wrong PR 😅

While I'm investigating, what happens if you run gh pr view or gh pr status?

And what is the output of this command?

git config --get-regexp ^branch\.kdavin/32685-database-tasks-resources-are-adjusted-to-avoid-CPUThrottling-and-memory-overprovionning-\.(remote|merge)$

The first one doesn't work at all:

And the other one is broken:

…ase-tasks-resources-are-adjusted-to-avoid-CPUThrottling-and-memory-overprovionning-:main via 🅶 v8.7-20240212001320+0000 via 🅺 872ms
❯ gh pr status

Relevant pull requests in gradle/ge

Current branch
  #22123  not-my-branch-nor-pr [main] - Closed

Created by you
  #32692  `database-tasks` resources are adjusted to avoi... [kdavin/32685-database-tasks-resources-are-adjusted-to-avoid-CPUThrottling-and-memory-overprovionning-]
  × 1/2 checks failing ✓ 1 Approved ✓ Auto-merge enabled
  …

Requesting a code review from you
  …

It stated my branch is #22123, which is not the case. PR is #32692

I had to quote it because of incompatibility with fish:

Re: #8758 (comment)

Yep, that all makes sense with the way pr comment is failing (I just wanted to check that this wasn't specific to pr comment).

Re: #8758 (comment)

Ok I can see what is happening here (though I'm not sure why we are in this state). The second line of your screenshot says:

kdavin/32685-database-tasks-resources-are-adjusted-to-avoid-CPUThrottling-and-memory-overprovionning-.merge refs/heads/main

This branch config (you can see it if you cat .git/config and search for your branch name tells git that your local branch kdavin/32685-database-tasks-resources-are-adjusted-to-avoid-CPUThrottling-and-memory-overprovionning- is tracking the remote branch main.. The GitHub CLI is reading this config to fill in the GraphQL request to figure out which PR to comment on. You can see the GraphQL variables in your debug output that the headRefName is main.

GraphQL query:
query PullRequestForBranch($owner: String!, $repo: String!, $headRefName: String!, $states: [PullRequestState!]) {
    repository(owner: $owner, name: $repo) {
      pullRequests(headRefName: $headRefName, states: $states, first: 30, orderBy: { field: CREATED_AT, direction: DESC }) {
        nodes {id,url,number,state,baseRefName,headRefName,isCrossRepository,headRepositoryOwner{id,login,...on User{name}}}
      }
      defaultBranchRef { name }
    }
  }
GraphQL variables: {"headRefName":"main","owner":"FOO","repo":"BAR","states":null}

So the obvious fix is to make sure that you are tracking the right upstream branch by running this from your current branch and then trying to comment again:

git branch -u origin/kdavin/32685-database-tasks-resources-are-adjusted-to-avoid-CPUThrottling-and-memory-overprovionning-

You can revert this by doing:

git branch -u origin/main

The question really is though, how did you end up with your branch in this state? What workflows do you use for creating and working with branches?

Got it. Indeed after running the command branch -u … it fixed it.

My process to create my branch is wrapped in a gh extension, and to summarize it does this:

git fetch
BASE_BRANCH="origin/${FROM_BRANCH}"
git checkout -b "kdavin/${ISSUE_ID}-${BRANCH_NAME}" "$BASE_BRANCH"

With all values provided as parameters:

$ gh create-branch 32685 main

And I think it's because origin/main as base branch translates to remote branch… instead of local. So it's the reason behind this issue.

But should gh understand it?

PS: it would be cool to have this directly and official in gh, like GitLab already has 😇

Hmmm, I wouldn't expect the commands you've provided there to result in this unless you have branch.autoSetupMerge configured to track (which I don't think is the default). It could also happen if you git push -u or git branch -u. Anyway, it certainly seems like something in your local flow that is resulting in this, and if we track that down everything should work again.

But should gh understand it?

I don't see how gh could figure this out. You've configured git to say that origin/main is your remote tracking branch.

PS: it would be cool to have this directly and official in gh, like GitLab already has 😇

Can you give an example of the glab command you'd use?

I do use the push.autoSetupRemote FYI, but not branch.autoSetupMerge.

I've updated my create-branch workflow, let's see how this works.

But I'm still surprised it worked for some branches, and even posted to other PR 🤷

Can you give an example of the glab command you'd use?

My workflow with glab is usually:

$ glab issue create
… do things in the terminal …
$ glab mr create --related-issue <number of the prev issue>
…

After that, I have my branch created, setup correctly by GitLab (right remote branch, not like the cause of this issue). It's the processed I tried to automate with my create-branch function.

This appears to be a confirmed bug with gh pr comment branch resolution - either targeting the wrong PR or failing to find the PR for the current branch. No confident duplicate was found (issue #7590 covers related branch-detection problems in gh pr status/gh pr view, but is a distinct enough scenario). I'm suggesting priority-3 because a workaround exists (passing the branch name explicitly: gh pr comment $(git rev-parse --abbrev-ref HEAD) -b "..."), the issue is intermittent without a clear reproducer, and it affects a limited set of configurations. If anyone can narrow down a consistent reproduction case - ideally with gh version output, OS, and the remote/branch configuration in use - that would help a maintainer investigate further.

Generated by Issue Triage (skills-driven) · 22.4 AIC · ⌖ 6.08 AIC · ⊞ 5K · ◷

Going to close this out due to housekeeping (it seems like it was an environmental issue upon skimming the issue). If there's still a problem that we can fix in gh, a new issue to describe what we should enhance would be helpful 🙏

Navigation Menu

Repository navigation

`gh pr [comment]` not working correctly for few days #8758

Agent suggestions

Describe the bug

Expected vs actual behavior

Logs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

gh pr [comment] not working correctly for few days #8758

Agent suggestions

Description

Describe the bug

Expected vs actual behavior

Logs

Activity

williammartin commented on Feb 26, 2024

davinkevin commented on Feb 26, 2024

davinkevin commented on Feb 26, 2024

williammartin commented on Feb 26, 2024

williammartin commented on Feb 26, 2024

davinkevin commented on Feb 26, 2024

davinkevin commented on Feb 26, 2024

williammartin commented on Feb 26, 2024

davinkevin commented on Feb 26, 2024

williammartin commented on Feb 26, 2024

davinkevin commented on Feb 26, 2024

cli-triage commented on Jul 9, 2026

BagToad commented on Jul 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`gh pr [comment]` not working correctly for few days #8758