Github sometimes closes issues that have been re-opened

[RalfJung]

When a commit contains the magic words Fixes #xxx, if that commit gets pushed to a repo by someone with permissions to close rust-lang issues, the issue will be closed. (I don't know the exact requirements, but it's something like this.) When a PR has these magic words in the PR description, that gets added to the merge commit message, and causes the same issue. This can lead to accidental issue closure when such a commit gets merged into our repo, then the issue gets reopened, and then the commit gets pushed somewhere.

I've seen this a few times over the last years. The most recent one is #102048.

@rust-lang/infra is there anything we can do here? Like disable the "auto close based on commit message" feature (but keep it for PR descriptions!)? If not, maybe this could be added to the wishlist for the next meeting you have with Github people.

[y21]

This has also happened a few times during a clippy subtree update which has commits that reference issues in the clippy repo but happen to have the same issue number as open issues here. #12695 is one such case

[jdno]

I've raised this via GitHub's support (thus not our call with them) a while back and they were aware of the issue. But there isn't a way to prevent this (afaik) and GitHub didn't seem confident that it would be fixed anytime soon. But we can flag this in our calls again...

[marcoieni]

One thing we could do is having a github actions/app that analyzes the commit messages of a PR and prevents patterns like fixes #\d . There are other patterns like "close", "closes", "fix", etc.

People would need to force push to change the commit message.

[nikic]

I think this can even happen when the commit is in a private repo, in which case the GitHub UI has no indication that the issue was actually closed due to a commit reference.