Skip to content

emrg: a declaration that closed without merging reads as work that landed #2603

Closed

Description

@pm25coder

What was observed

scripts/check-issue-links.py puts one row on every open issue and, when no open PR declares it, reports UNCLAIMED and names the declarers that have closed. For a PR that closed without merging, the row printed:

#30 declared Closes #10 and are merged or closed, which is the shape of work that landed and was never closed - either close this issue with the reading that says the work is done, or open the PR that finishes it

None of that work is on master. The remedy asks the reader to close the issue on a reading that is false, and the sentence is the one a reader acts on.

Where it comes from

judge_issues, the unclaimed branch. The cause is a single field: Refs.declared_closed held both the merged declarers and the closed-unmerged ones, and the only thing that separates them is pull_request.merged_at on the same cross-referenced event.

The module already states that distinction three times elsewhere, which is what makes this a defect rather than a judgement call:

  • referencing_prs reads merged_at rather than state, "because state is closed for a merge, for an abandoned PR and for a closed issue alike, and reading the state would call abandoned work landed";
  • _mention_detail splits landed from abandoned for a referrer that did not declare the issue, and names the measured reason (an idle issue and one whose work landed must not read alike);
  • the field's own docstring called a closed unmerged declarer "simply abandoned work".

So the two clauses that describe the pair in prose and the one field that stored it disagreed, and no test pinned the field.

Expected instead

Two states, two remedies, because the reader's next move is opposite in each:

  • merged — the work is on master and the issue is stale: close it with that reading, or state here what it still leaves;
  • closed without merging — none of that work is on master and the issue is not stale: continue that branch and reopen it, rather than opening a second PR for the same issue.

What the fix must satisfy

  1. A declarer that merged reads as landed work; a declarer that closed without merging does not.
  2. The two are told apart by merged_at, never by state.
  3. An issue carrying one of each is told about both, since a reader given only the first would close the issue over work that does not finish it.
  4. A test whose fixture differs from the merged one in that single field — so a reading that goes by state answers both the same way and fails.

Note on the existing coverage

The one test that asserted this sentence was named "A merged PR that declared the issue, with the issue still open", while its fixture built state="closed" with no merged_at — a closed, never-merged PR. It passed precisely because the field conflated the two, so the test asserted the defect rather than the behaviour. The same change makes that fixture actually merge.

Activity

  1. pm25coder commented on Oct 27, 2026

    @pm25coder
    CollaboratorAuthor

    Handled by #2604

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions