Skip to content

fix: preserve GraphQL error type for scope errors in handleResponse#12913

Closed
yuvrajangadsingh wants to merge 1 commit intocli:trunkfrom
yuvrajangadsingh:fix/scope-error-regression-12904
Closed

fix: preserve GraphQL error type for scope errors in handleResponse#12913
yuvrajangadsingh wants to merge 1 commit intocli:trunkfrom
yuvrajangadsingh:fix/scope-error-regression-12904

Conversation

@yuvrajangadsingh
Copy link
Contributor

@yuvrajangadsingh yuvrajangadsingh commented Mar 12, 2026

Fixes #12904

PR #12596 added GenerateScopeErrorForGQL() inside handleResponse(), which rewrites INSUFFICIENT_SCOPES GraphQL errors into plain fmt.Errorf strings before callers see them. This broke ProjectsV2IgnorableError() which checks for the original API substring to silently suppress read:project scope errors.

After the rewrite, gh pr view, gh pr edit, gh issue view etc. all fatally error instead of gracefully ignoring the missing project scope.

The fix removes GenerateScopeErrorForGQL from handleResponse() so scope errors flow through as GraphQLError like any other GraphQL error. ProjectsV2IgnorableError can then match the original message and suppress it as intended.

gh project commands still get user-friendly scope messages through their own handleError in pkg/cmd/project/shared/queries, which already calls GenerateScopeErrorForGQL independently.

Changes:

  • api/client.go: removed scope error rewriting from handleResponse
  • api/queries_projects_v2_test.go: added regression test that verifies scope errors remain ignorable after passing through handleResponse

@yuvrajangadsingh
fix: preserve GraphQL error type for scope errors in handleResponse
e8ab78c 
Fixes cli#12904

handleResponse was rewriting INSUFFICIENT_SCOPES GraphQL errors into
plain fmt.Errorf strings via GenerateScopeErrorForGQL. This destroyed
the original error message that ProjectsV2IgnorableError relies on
to silently suppress read:project scope errors.

Removed the GenerateScopeErrorForGQL call from handleResponse so scope
errors flow through as GraphQLError like any other GraphQL error.
Project commands still get user-friendly scope messages through their
own handleError in pkg/cmd/project/shared/queries.
@yuvrajangadsingh yuvrajangadsingh requested a review from a team as a code owner March 12, 2026 10:35
@github-actions
Copy link

github-actions bot commented Mar 12, 2026

Thanks for your pull request! Unfortunately, it doesn't meet the minimum requirements for review:

  • None of the referenced issues have the help wanted label

Please update your PR to address the above. Requirements:

  1. Include a detailed description of what this PR does
  2. Link to an issue with the help wanted label (use Fixes #123 or Closes #123 if it resolves the issue)

This PR will be automatically closed in 7 days if these requirements are not met.

@github-actions github-actions bot added external pull request originating outside of the CLI core team needs-triage needs to be reviewed labels Mar 12, 2026
This was referenced Mar 12, 2026
Closed
Merged
@yuvrajangadsingh
Copy link
Contributor Author

yuvrajangadsingh commented Mar 12, 2026 •
edited
Loading

@BagToad @camjac251 this is a regression from #12596 (merged last month) that breaks gh pr view, gh pr edit, gh issue view for any token without read:project scope. issue #12904 was just filed today so it probably needs the help wanted label. the fix is 4 lines removed + a regression test.

@babakks
Copy link
Member

babakks commented Mar 12, 2026 •
edited
Loading

First, huge thanks for your support in digging this problem and being proactive to submit a fix for it, @yuvrajangadsingh! 🙏

I believe we have to close this PR as the original enhancements made in those recent PRs were not actually in the right direction (not just bogus I mean). So, @williammartin and I decided to revert those two PRs in #12915 and #12914.

Quoting from @williammartin:

We could move this forward, but I actually think the implementation in that PR was incorrect because it previously showed an error message that made sense for personal access tokens and was changed to a message that only made sense for OAuth tokens. And so it just sort of swapped the problem around. I'm gonna reopen that issue, but if we were to address it again we would need to interrogate the type of token or provide an error message that covered both cases.

@babakks babakks closed this Mar 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@BagToad BagToad Awaiting requested review from BagToad BagToad is a code owner automatically assigned from cli/code-reviewers

Assignees

No one assigned

Labels

external pull request originating outside of the CLI core team needs-triage needs to be reviewed

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Spurious missing read:project scope warnings

3 participants

@yuvrajangadsingh @babakks @williammartin