Note the sticky closing-issue links in the PR-workflow skill - #518
Merged
Conversation
Merging PR #514 closed #512, which its body said had been filed rather than fixed. The link came from an earlier draft of the body: GitHub registers a closing reference when the text is first saved and keeps it after the text is edited away, so neither the current body nor the branch's commit messages show it. `gh pr view <N> --json closingIssuesReferences` is the only thing that does. Also records the recovery, since reopening is not the whole of it: the board automation moves a closed issue to Done, and a reopen lands on In Progress rather than Todo. Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a "check what the merge will close" step to the
github-issue-pr-workflowskill.Why
When #514 merged, it took
issue 512 down with it — an issue that PR had deliberately left alone, and whose body said as much
("Two things noticed in passing, filed rather than fixed"). Issue 512 has since been reopened, with
its project Status put back to Todo.
A closing reference turns out to be sticky. GitHub registers the link when text containing the
keyword is first saved, and does not drop it when that text is edited away. An early draft of
#514's body must have carried one; by merge time no trace remained in either the body or the
branch's five commit messages, yet the link was still live:
So that field is the only reliable check. Reading the body is not evidence, and neither is grepping
the commits.
I confirmed the stickiness on this PR's own first attempt, which used the word "closed" directly
before a link to the issue and so registered the same link. Editing the phrase out left the
reference in place ninety seconds later, which is why this PR was opened afresh rather than edited.
What the note says
The command to run before
gh pr merge, why the current body cannot be trusted, and how torecover — because reopening is not the whole of it. The board automation moves a closed issue to
Done, and a reopen lands it on In Progress, not back on Todo, so the project field has to be
set explicitly.