Pull requests referencing Trac tickets are not being closed when noted as fixed in commit messages

[desrosj]

The cleanup-pull-requests.yml workflow checks for any open pull requests that reference tickets noted as fixed in a given commit message. It appears that something has either changed or is broken within GitHub's search as the current methods of searching does not return results.

I noticed this after [63309] closed #65864, but the ​corresponding pull request was not closed.

The search query currently in place is repo:WordPress/wordpress-develop is:pr is:open ("https://core.trac.wordpress.org/ticket/65864" OR "core-65864"), but ​this search shows no results.

Trying different search queries:

• Searching for https://core.trac.wordpress.org/ticket/65864 does not return any results despite being explicitly included as a link in the PR description.
• Searching Core-65864 does return the expected result. However this is strange because Core-65864 is not explicitly included in pull request. "Core-65864" does not return results.

[desrosj]

Strangely, the workflow successfully closed this pr: ​https://github.com/WordPress/wordpress-develop/pull/13061.

[siliconforks]

Replying to desrosj:

Strangely, the workflow successfully closed this pr: ​https://github.com/WordPress/wordpress-develop/pull/13061.

I think that one worked because it has the full URL in the text of the PR (not just as a hyperlink created with Markdown).

Contrast that with ​https://github.com/WordPress/wordpress-develop/pull/13021 which does not have the full URL in the text itself, it just has a link.

This is probably why the ​documentation says "Open a PR to wordpress-develop with the full URL for the Trac ticket in the PR body."

I'm not sure if it's possible to improve this behavior? It looks like GitHub search simply can't find a URL if it's in a hyperlink - it can find it only if the URL is in the actual text.

The reusable-cleanup-pull-requests.yml workflow closes open PRs that reference a Trac ticket noted as fixed in a commit message. It does this by searching GitHub for PRs whose body contains either the full Trac ticket URL or a core-<id> string, then double-checks the match against the PR's body text before closing it.

Both the search and the double-check miss PRs that reference the ticket as a Markdown link with just the ticket number as the link text (e.g. Trac ticket: [https://core.trac.wordpress.org/ticket/65864 65864]), which the PR template's own wording ("a link to the WordPress Trac ticket") doesn't rule out. GitHub's search index only covers a PR's rendered/visible text, not Markdown link targets, so the URL search term never matches this style. The double-check filter had the same problem in a second way: it read the bodyText field, which strips Markdown links down to their visible text and drops the URL entirely, so even a PR that *did* surface via search would fail the manual re-check.

This fixes both:

• Adds the bare ticket number as a third alternative search term, since GitHub's index does cover the plain ticket number when it's the visible text of a link.
• Switches the manual re-check from bodyText to the raw body field, which retains the literal URL even inside a Markdown link, so the widened search doesn't introduce false positives from unrelated PRs that merely mention the same number.

Verified against the real GitHub GraphQL API using ticket #65864 (the ticket cited in the bug report) — the current search misses PR #13021 (Markdown-link style), and the widened query surfaces it. Also unit-verified the body-matching logic in isolation against a plain-URL body, a Markdown-link body, a core-<id> body, and a deliberately unrelated body that just happens to mention the same number — the fix matches the first three and correctly rejects the last. actionlint and zizmor both pass clean on the modified file.

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Sonnet 5
Used for: Root-cause investigation (via GitHub's GraphQL API), implementation, and PR description. Reviewed by Igor Rozum.