Skip to content

fix(#397): guard the gh-pr-edit workaround, since the repo cannot fix gh itself - #807

Merged
TortoiseWolfe merged 1 commit into
mainfrom
fix/397-guard-gh-pr-edit-workaround
Aug 18, 2026
Merged

fix(#397): guard the gh-pr-edit workaround, since the repo cannot fix gh itself#807
TortoiseWolfe merged 1 commit into
mainfrom
fix/397-guard-gh-pr-edit-workaround

Conversation

@TortoiseWolfe

Copy link
Copy Markdown
Owner

gh pr edit fails on every invocation against this repo. Its GraphQL pre-fetch asks for
repository.pullRequest.projectCards — a Projects (classic) field GitHub has sunset — so the
server rejects the whole query before any edit is attempted.

Re-verified today, probed with a deliberately invalid label so nothing could mutate:

$ gh pr edit 806 --repo TortoiseWolfe/ScriptHammer --add-label "zz-not-a-real-label-397-probe"
GraphQL: Projects (classic) is being deprecated ... (repository.pullRequest.projectCards)
exit 1

gh issue edit, gh pr merge and gh api are unaffected.

This is Refs, not Closes — deliberately

The repo cannot fix it. The bug is in the CLI's own query, and gh 2.46.0 is from January
2025. The remaining action is an environment change — upgrade gh — so #397 stays open, and is
retitled to say that rather than reading as a repo defect somebody could go fix in here.

What the repo can do, and now does

scripts/__tests__/gh-pr-edit-is-avoided.test.js (in pnpm test:scripts, so inside the required
Test (20.x) check) asserts:

  1. no script, workflow or hook calls gh pr edit — distinguishing a call site from prose,
    so CLAUDE.md and the test itself can still name the command out loud;
  2. CLAUDE.md still carries the REST workaround, in runnable form, so a docs tidy cannot leave
    the warning standing without its remedy.

Why a test and not just the note

The failure is quiet in the way that matters: non-zero exit, but a message that reads like a
deprecation notice, on stderr. Wrapped as cmd >/dev/null 2>&1 && echo ok || echo FAILED it
reports FAILED with no visible reason — which is exactly how it was originally found, one line
in a batch of five that looked like an unrelated permissions problem. A script that adopted
gh pr edit would keep working right up until it silently stopped.

Mutation-verified, both halves

mutation result
add a real call site fails naming scripts/ci/zz-mutant.sh:2
replace the gh api -X PATCH line in CLAUDE.md fails with "the warning is not actionable"

Controls prove the detector separates prose from a call site in both directions — a guard that
flagged the documentation would be deleted by the first person it annoyed.

To close #397

Upgrade gh, re-run the probe above, and if it succeeds delete both the CLAUDE.md note and this
test. That test failing after an upgrade is the signal the workaround is no longer needed
not a regression.

pnpm test:scripts: 374 passed

Refs #397

… gh itself

`gh pr edit` fails on EVERY invocation against this repo. It pre-fetches the PR through
GraphQL and that query asks for `repository.pullRequest.projectCards` -- a Projects
(classic) field GitHub has sunset -- so the server rejects the whole query before any
edit is attempted.

Re-verified today on gh 2.46.0, probed with a deliberately invalid label so nothing could
mutate: exit 1, same `projectCards` error. `gh issue edit`, `gh pr merge` and `gh api`
are unaffected.

THE REPO CANNOT FIX THIS. The bug is in the CLI's own query and 2.46.0 is from January
2025; the remaining action is a `gh` upgrade, which is an environment change. So this is
`Refs`, not `Closes`, and #397 is retitled to say "upgrade gh" rather than reading as a
repo defect somebody could go fix in here.

What the repo CAN do is stop depending on the broken path and stop the workaround being
tidied away. scripts/__tests__/gh-pr-edit-is-avoided.test.js asserts:

  - no script, workflow or hook calls `gh pr edit` -- distinguishing a CALL SITE from
    prose, so CLAUDE.md and the test itself can still name the command out loud;
  - CLAUDE.md still carries the REST workaround, in runnable form, so a docs tidy cannot
    leave the warning standing without its remedy.

WHY A TEST AND NOT JUST THE NOTE. The failure is quiet in the way that matters: non-zero
exit, but a message that reads like a deprecation NOTICE, on stderr. Wrapped as
`cmd >/dev/null 2>&1 && echo ok || echo FAILED` it reports FAILED with no visible reason
-- which is exactly how it was originally found, one line in a batch of five that looked
like an unrelated permissions problem. A script that adopted `gh pr edit` would keep
working right up until it silently stopped.

Both halves mutation-verified with the mutant confirmed present first: adding a real call
site fails it naming `scripts/ci/zz-mutant.sh:2`, and replacing the `gh api -X PATCH`
line in CLAUDE.md fails it with "the warning is not actionable". Controls prove the
detector separates prose from a call site in both directions.

To close #397: upgrade gh, re-run the probe, and if it succeeds delete both the CLAUDE.md
note and this test. That test failing after an upgrade is the signal the workaround is no
longer needed -- not a regression.

pnpm test:scripts: 374 passed.

Refs #397
@TortoiseWolfe
TortoiseWolfe merged commit 8523a73 into main Aug 18, 2026
28 checks passed
@TortoiseWolfe
TortoiseWolfe deleted the fix/397-guard-gh-pr-edit-workaround branch August 18, 2026 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Upgrade gh: 2.46.0's 'gh pr edit' queries a sunset Projects-classic field and fails on every PR edit (repo side now guarded)

2 participants