grunt patch fails for every ticket: Trac returns a bot challenge instead of the attachment list

Summary

grunt patch:<ticket> no longer works for any ticket. Trac now answers requests from non-browser clients with a proof-of-work bot interstitial instead of the page, so the attachment list can never be read and no patch is ever found.

This is a server-side change at WordPress.org, not a regression in this package — but the package cannot currently do its job, and the error it prints sends people looking in the wrong place.

Reproduction

Using the tool's own literal User-Agent against its own endpoint:

curl -s -o /dev/null -w '%{http_code}\n' \
  -A "grunt-patch-wordpress; https://github.com/WordPress/grunt-patch-wordpress" \
  "https://core.trac.wordpress.org/attachment/ticket/62281/"

Result: 403. The body is a Checking your browser… page — a SHA-256 hashcash challenge that sets an _hcc cookie and escalates to an "I am human" checkbox on repeat requests.

The same applies to /raw-attachment/ticket/<id>/<file>, so the download step in getPatch() is blocked as well as the listing step. Sending a browser User-Agent instead returns a bare nginx 403. Verified 2026-08-06 from an ordinary home connection, not a datacentre IP.

What the user sees

Both request sites treat any non-200 the same way:

• tasks/patch_wordpress.js:238-244 — getPatchFromTicket() emits fileFail on a non-200
• tasks/patch_wordpress.js:279-283 — getPatch() does the same

fileFail() then prints "Nothing to patch." followed by the four-point usage help — "enter a ticket number, enter a ticket url, enter a patch url". So a contributor whose ticket definitely has patches on it is told, in effect, that they typed the command wrong. The 403 is in the emitted message but is buried under generic usage advice, and nothing indicates the request was blocked rather than empty.

Suggested direction

The real fix is almost certainly not in this package. Two paths, neither of which this repo controls:

• An allowlist for an identified client User-Agent, which would need Systems.
• A structured read API. meta #8202 proposes JSON endpoints exposing ticket metadata and the attachment list (filename, author, date, size), which would remove the scraping dependency entirely rather than restoring it. It is assigned and has an implementation in progress.

What is in scope here, and worth doing regardless: say what actually happened. Detecting the challenge response and printing something like "Trac returned a bot-protection challenge (403); this tool cannot currently fetch attachments" would stop people debugging their own ticket number, and would make the scale of the problem visible instead of looking like scattered user error.

Related

• #83 (list PRs along with patches) needs the same ticket data, and would be unblocked by the same API rather than by more scraping.
• Worth noting for #70: whatever succeeds this tool will hit exactly this wall unless it consumes a real API, so the successor's data source may matter more than its build tooling.

Start in tasks/patch_wordpress.js at getPatchFromTicket() and getPatch(), where non-200 responses reach fileFail(). Reproduce the 403 challenge response with the curl command in the issue, then trace how the current message is assembled. Done means a bot-protection response is identified and reported clearly instead of being presented as an empty patch or generic usage error.