Closing a PR quickly makes the following PR fail checks and not run PR workflow

[AskeHolst]

When making a PR into a release branch it often happens that the PR is made on main by mistakes as that is the default suggestion. This is usually quickly discovered and the PR is closed. But by then the PR workflow has started.
The PR workflow will then fail with the error below because the PR no longer exists. This is minor annoyance.

When the proper PR is then created on the release branch it will incorrectly pick up the failed checks from the workflow run on the previous PR. This causes confusion as to why checks are failing.
It also means that the PR workflow will never run on the new PR.

Run actions/checkout@v3
Syncing repository: [REDACTED]/[REDACTED]
Getting Git version info
Temporarily overriding HOME='D:\a\_temp\7d97[35](https://github.com/prymeGlobal/prymeTime/actions/runs/4693766182/jobs/8321167271#step:2:37)e8-02a4-[49](https://github.com/prymeGlobal/prymeTime/actions/runs/4693766182/jobs/8321167271#step:2:54)3d-b86c-e8[51](https://github.com/prymeGlobal/prymeTime/actions/runs/4693766182/jobs/8321167271#step:2:56)7b7a2b4a' before making global git config changes
Adding repository directory to the temporary git global config as a safe directory
"C:\Program Files\Git\bin\git.exe" config --global --add safe.directory D:\a\[REDACTED]\[REDACTED]
Deleting the contents of 'D:\a\[REDACTED]\[REDACTED]'
Initializing the repository
Disabling automatic garbage collection
Setting up auth
"C:\Program Files\Git\bin\git.exe" lfs install --local
Updated Git hooks.
Git LFS initialized.
Fetching the repository
  "C:\Program Files\Git\bin\git.exe" -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/pull/82/merge:refs/remotes/pull/82/merge
  Error: fatal: couldn't find remote ref refs/pull/82/merge
  The process 'C:\Program Files\Git\bin\git.exe' failed with exit code 128
  Waiting 13 seconds before trying again
  "C:\Program Files\Git\bin\git.exe" -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/pull/82/merge:refs/remotes/pull/82/merge
  Error: fatal: couldn't find remote ref refs/pull/82/merge
  The process 'C:\Program Files\Git\bin\git.exe' failed with exit code 128
  Waiting 15 seconds before trying again
  "C:\Program Files\Git\bin\git.exe" -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +refs/pull/82/merge:refs/remotes/pull/82/merge
  Error: fatal: couldn't find remote ref refs/pull/82/merge
  Error: The process 'C:\Program Files\Git\bin\git.exe' failed with exit code 128

[freddydk]

@aholstrup1 - do you know what is happening here?

[AskeHolst]

Note that it does not have to be PRs for different branches.

• Create a PR main<-MyBranch
• PR 1 'MyBranch' is created
• Close PR 1 'MyBranch' immediately
• See the PR workflow fail for PR 1 'MyBranch'
• Create a new PR main<-MyBranch
• PR 2 'MyBranch' is created
• The checks for PR 1 'MyBranch' shows up in PR 2 'MyBranch'
• No PR workflow for PR 2 'MyBranch' is run

[aholstrup1]

Thanks for reporting this @AskeHolst. As you also mentioned, PR Builds will fail if you close the PR since the merge commit created by GitHub no longer exists.
As for GitHub picking up the checks from the previous PR, I tried following the steps you shared in your previous comment but I couldn't reproduce. Is this something that is happening consistently on your end or only occasionally? When I open the PR for the second time it briefly shows the wrong checks, but within a few seconds it submits a new PR Build and shows the correct checks after that.

[AskeHolst]

Would be possible to have it fail more gracefully, simply canceling the process if the PR no longer exists? Everybody freaks out when pipelines fail as emails a sent out to those following the repo.

I can consistently repro the problem in a test repo. But you are right, if you wait for a runner to pick up the job then it will correct itself. People just don't wait that long, they create the PR, see failed checks with red marks and think they made some mistake. Maybe this is then a documentation issue to tell people to not trust what they see initially, I just don't like that message.

[AskeHolst]

We sometimes see that the new PR will not be picked up by a workflow, so we are stuck with the failed checks. I do not see a pattern for this.

[freddydk]

We sometimes see that the new PR will not be picked up by a workflow, so we are stuck with the failed checks. I do not see a pattern for this.

Will lookout for this - haven't seen it

[freddydk]

I have seen this some times now, and it is fairly confusing. Not sure if anything can be done to make the failure message a little more descriptive.