ci(pr): the changes job survives an un-renderable diff and no longer fails open on large file lists

[DeusData]

Two defects in the changes job of pr.yml, both hitting exactly the PRs that change the most. One fails closed for the wrong reason, the other fails open.

1. The file-list API answers 422 for a PR that regenerates a vendored parser

changes decides whether a PR touches product code, and ci-ok requires it. It asks pulls/{n}/files for the file list. That endpoint renders the diff server-side, and for #2246 (a 42 MB sql/parser.c) it answers

HTTP 422: Sorry, this diff is taking too long to generate.

The compare endpoint fails the same way, so there is no API route to the list for such a PR. Result: changes red, therefore ci-ok red, for a reason that has nothing to do with the contribution. Every grammar refresh would hit this.

Fix: when the API call fails, take the list from git. The PR merge ref's first parent is the base, so a name-only diff across that one merge commit is the PR's file list. The fetch is --depth=2 --filter=blob:none into a bare repository under RUNNER_TEMP: commits and trees only, nothing checked out, nothing from the PR executed. No new action, no new permission; the API path and the classification regex are untouched, so ordinary PRs behave exactly as before. A ::notice:: records when the fallback was used. If the fetch fails too, the step exits non-zero and writes no output — the gate still fails closed.

2. The classification reported a MATCH as "no product change" on large file lists

if printf '%s\n' "$FILES" | grep -qE '^(src/|internal/|...)'; then

runs under the runner's bash -eo pipefail. grep -q exits on its first match; once the list is larger than the pipe buffer, printf is still writing, dies of SIGPIPE, and pipefail turns the match into a failed pipeline. The else branch then writes product=false, and pr-smoke and memwaste are skipped — on the largest PRs. It takes roughly 1,500 changed files to cross the buffer, which is why ordinary PRs never showed it.

Fix: the list reaches grep through a here-string, so there is no pipe to break. The regex is unchanged.

Proof

By executing the workflow's own run: block under bash -eo pipefail with a stub gh, ten runs each where it matters:

case	before	after
849 KB list, first line src/a.c	product=false 10/10	product=true 10/10
849 KB list, docs only	product=false	product=false
small docs-only list, API path	product=false	product=false
422 fallback on the real #2246	step fails	product=true, the same five files git diff --numstat reports; 0.85 s, 188 KB fetched
fallback, nonexistent merge ref	—	rc 128, no output written

The contract tests that read pr.yml — security_gate_fail_closed, smoke_fixture_contract, windows_bundle_contract, venue_parity_contract — pass on this branch.

Scope

One file, .github/workflows/pr.yml, one step of one job: +22/−2. No trigger, permission, action or secret changes.