[BUG] Sometimes rerequested check_run events don't contain a PR list

The same app is installed into several orgs. In one test org when I click “Re-run” here https://github.com/sanitizers/browntruck/pull/1/checks?check_run_id=162132498 it has a non-empty list under check_run->check_suite->pull_requests. And for other orgs (namely, tox-dev and aio-libs) it’s empty when I click it @ https://github.com/aio-libs/aiohttp/pull/3804/checks?check_run_id=163078825, for example.

Broken:

{
"action":"rerequested",
"check\_run": {
    ...,
"output": {
"title":"Timeline protection: History fragments missing",
"summary":"Oops... This change does not have a record in the archives. Just as if it never happened!\n\n![Keeping chronicles is important](https://theeventchronicle.com/wp-content/uploads/2014/10/vatlib7.jpg)",
"text":"No files matching re.compile('CHANGES/(?P\<issue\_number\>[^\\\\./]+)\\\\.(?P\<fragment\_type\>bugfix|doc|feature|removal|trivial|vendor)(\\\\.\\\\d+)?(\\\\.[^\\\\./]+)\*$') pattern added",
"annotations\_count":0,
"annotations\_url":"https://api.github.com/repos/aio-libs/aiohttp/check-runs/163078825/annotations" },
"name":"Timeline protection",
"check\_suite": {
"id":157188790,
"node\_id":"MDEwOkNoZWNrU3VpdGUxNTcxODg3OTA=",
"head\_branch":null,
"head\_sha":"df644394d03c0076678f4ebc95c5d99d743ab3f2",
"status":"completed",
"conclusion":"failure",
"url":"https://api.github.com/repos/aio-libs/aiohttp/check-suites/157188790",
"before":null,
"after":null,
"pull\_requests": [

      ],
      ...,
"created\_at":"2019-07-06T16:45:49Z",
"updated\_at":"2019-07-06T16:45:50Z" },
    ...,
"pull\_requests": [

    ]
  },
  ...
}

Correct:

{
"action":"rerequested",
"check\_run": {
    ...,
"name":"Timeline protection",
"check\_suite": {
      ...,
"pull\_requests": [
        {
"url":"https://api.github.com/repos/sanitizers/browntruck/pulls/1",
"id":235276563,
"number":1,
"head": {
"ref":"feature/github-app-aiohttp",
"sha":"f2114ef3a920b908d091aaeb9377a119807f0380",
"repo": {
"id":160039456,
"url":"https://api.github.com/repos/sanitizers/browntruck",
"name":"browntruck" }
          },
"base": {
"ref":"master",
"sha":"6869c0bad05e74c5de5aaa6ff9f74e35b9626b6d",
"repo": {
"id":160039456,
"url":"https://api.github.com/repos/sanitizers/browntruck",
"name":"browntruck" }
          }
        }
      ],
      ...
    },
    ...,
"pull\_requests": [
      {
"url":"https://api.github.com/repos/sanitizers/browntruck/pulls/1",
"id":235276563,
"number":1,
"head": {
"ref":"feature/github-app-aiohttp",
"sha":"f2114ef3a920b908d091aaeb9377a119807f0380",
"repo": {
"id":160039456,
"url":"https://api.github.com/repos/sanitizers/browntruck",
"name":"browntruck" }
        },
"base": {
"ref":"master",
"sha":"6869c0bad05e74c5de5aaa6ff9f74e35b9626b6d",
"repo": {
"id":160039456,
"url":"https://api.github.com/repos/sanitizers/browntruck",
"name":"browntruck" }
        }
      }
    ]
  },
  ...
}
2 Likes

I have the same problem, even though this is documented behavior. I can’t quite work out how I would get this information. https://github.community/t5/GitHub-API-Development-and/API-v3-What-causes-a-check-run-suite-pull-request-field-to-be/m-p/23646

1 Like

If you’re having an issue consistently within specific orgs but not others, I would suspect that it is a permissions issue rather than a bug. It also appears that in the “broken” link that the branch being merged is from a forked repository whereas the successful one is being merged from within the repository itself. Can you confirm that this is consistently the case in the “broken” scenarios?

1 Like

This is an interesting suggestion. App privileges are the same. And also PRs from the same repo don’t have such problem.

It looks like the issue @ekohl linked above.

But it’s still weird that it works like this from the UX perspective:

This commit is in the same Git tree, even though it’s in a fork. GitHub can even display it under the upstream repo URL while “technically” not having it there: https://github.com/aio-libs/aiohttp/pull/3804/commits/a89226d9dc796bcad3b806c02d5cbd73e5f7539fhttps://github.com/aio-libs/aiohttp/commit/a89226d9dc796bcad3b806c02d5cbd73e5f7539f.

So GitHub is able to locate and show the commit as a part of the related Git tree. I think it’s quite expected that it’d also backtrack that in the webhook payload.

P.S. I know that PRs produce an ephemeral/artificial “merge commit”. If I post Check API updates against that commit, will the events contain the PRs list?

Same here. My webhook is getting a check_run event with the payload

{
  "action": "REQUESTED_ACTION",
  "check_run": {
    "head_sha": "74b075adcf9c6628dd66f0a5f45b122f001909dd",
    "pull_requests": [],
    ...
  },
  ...
}

I’ve verified that that commit hash matches the commit in the PR, so I’m confused why GitHub might be sending an empty array in check_run.pull_requests.

1 Like