Skip to content

Conversation

gonzaloriestra
Copy link
Contributor

WHY are these changes introduced?

WHAT is this pull request doing?

  • Removes the stack trace for GraphQL errors
  • Do not report user errors as unexpected

How to test your changes?

Measuring impact

How do we know this change was effective? Please choose one:

  • n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
  • Existing analytics will cater for this addition
  • PR includes analytics changes to measure impact

Checklist

  • I've considered possible cross-platform impacts (Mac, Linux, Windows)
  • I've considered possible documentation changes

Copy link
Contributor

github-actions bot commented Sep 5, 2025

Coverage report

St.
Category Percentage Covered / Total
🟡 Statements
78.54% (+0.01% 🔼)
13482/17165
🟡 Branches
72.56% (+0.05% 🔼)
6550/9027
🟡 Functions
78.82% (+0% 🔼)
3505/4447
🟡 Lines
78.9% (+0.01% 🔼)
12744/16152

Test suite run success

3228 tests passing in 1358 suites.

Report generated by 🧪jest coverage report action from 1580630

mappedError = new GraphQLClientError(errorMessage, status, error.response.errors)
} else {
// eslint-disable-next-line @typescript-eslint/no-explicit-any
if (error.response.errors?.every((graphqlError: any) => graphqlError.type === 'GraphApi::UserError')) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems reversed? Wouldn't we want user errors to return GraphQlClientError and any other error to abort?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would make sense looking at the function names, but in reality I think that:

  • AbortError reports as handled
  • GraphQLClientError reports as unhandled

So maybe we need a bigger refactor here to simplify and make it clearer

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like it's hard, without context of the specific call, to qualify a 4xx error as always expected. If the CLI code is expecting to hit a server, and the CLI thinks the user is authenticated for example, then a 401 is probably unexpected since from the CLI's point of view, it assumed the user was authenticated.

So I don't know if we can globally categorize all these errors in one pass or not, or if we have to be a bit more precise and tackle each individual 401/403 case by case

Copy link
Contributor Author

@gonzaloriestra gonzaloriestra Sep 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, I believe we shouldn't report errors that may be caused by users as unhandled. For example, a user with a wrong token in CI could artificially inflate our stats.

Using that same example, there's no way for the CLI to know if that 401 is expected or not. Maybe we can in some specific cases, like right after a full auth flow. I'll give it a try to distinguish them, but I think it's better to not report by default.

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.

3 participants