Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalize REST error parsing #1494

Merged
merged 1 commit into from
Aug 10, 2020

Conversation

mmontes11
Copy link
Contributor

@mmontes11 mmontes11 commented Aug 6, 2020

Fixes #1474

Changes:

Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

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

Thank you for your contribution! 🌟

}
type errorResponse struct {
Message string
Errors []errorMessage
Copy link
Contributor

@mislav mislav Aug 6, 2020

Choose a reason for hiding this comment

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

When unmarshaling a field whose value is unknown at compile time (here, we don't know if the type is []errorMessage or []string), it's best to use []json.RawMessage as the type, and then check whether its 1st byte is a { or a " and with that decide whether you want to decode it to an errorMessage type or a string.

The goal would be to avoid unmarshalling into one struct and then catching an error and unmarshalling into another struct, since that approach is brittle and doesn't give us a lot of flexibility.

Copy link
Contributor Author

@mmontes11 mmontes11 Aug 6, 2020

Choose a reason for hiding this comment

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

Totally agree with you @mislav , your approach is way more flexible. I will work on a solution.

Header: http.Header{"Content-Type": []string{"application/json; charset=utf-8"}},
},
err: cmdutil.SilentError,
stdout: `{"errors": ["AGAIN", "FINE"]}`,
Copy link
Contributor

@mislav mislav Aug 6, 2020

Choose a reason for hiding this comment

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

GraphQL error messages are always guaranteed to be in the {"message": "..."} format. If you look closely at the original issue you were aiming to fix, the error response in question is from a REST API, not a GraphQL one.

So I think your direction to fix it is in general good, it's just that this test (and the PR description) needs to be reworded to indicate that it's covering a REST response!

Copy link
Contributor Author

@mmontes11 mmontes11 Aug 6, 2020

Choose a reason for hiding this comment

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

Agreed!

@mmontes11 mmontes11 changed the title Generalize GraphQL error parsing Generalize REST error parsing Aug 6, 2020
@mmontes11
Copy link
Contributor Author

changes done @mislav, check them out and let me know if they fit your approach 😃

@mmontes11 mmontes11 force-pushed the generalize-gql-error-parsing branch from 8feb7b0 to 6522984 Compare August 7, 2020 07:01
if err != nil {
return r, "", err
}
objectErrors = append(objectErrors, objectError)
Copy link
Contributor

Choose a reason for hiding this comment

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

Tip: why keep a separate slice of objectErrors when you can just append objectError.Message to stringErrors and simplify the whole logic

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Less code and unified error handling like in my first approach 👍🏻

@@ -265,7 +265,7 @@ func Test_apiRun(t *testing.T) {
stderr: "gh: THIS IS FINE (HTTP 400)\n",
},
{
name: "GraphQL error",
name: "REST object error",
Copy link
Contributor

Choose a reason for hiding this comment

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

This is a test for a GraphQL error response. Note the request path is graphql. I don't think this test case needed renaming

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I will restore the original name.

Comment on lines 283 to 281
options: ApiOptions{
RequestPath: "graphql",
Copy link
Contributor

Choose a reason for hiding this comment

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

You can omit ApiOptions with RequestPath entirely here; it's only necessary for testing GraphQL responses

Copy link
Contributor Author

@mmontes11 mmontes11 Aug 7, 2020

Choose a reason for hiding this comment

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

Ok, in that case I will specify an error code 400 since it is a REST operation.

@mmontes11 mmontes11 force-pushed the generalize-gql-error-parsing branch from 6522984 to 0b395e0 Compare August 7, 2020 12:11
@mmontes11
Copy link
Contributor Author

mmontes11 commented Aug 7, 2020

changes pushed @mislav, thank you for your detailed feedback!

@mmontes11 mmontes11 force-pushed the generalize-gql-error-parsing branch from 0b395e0 to eaa9f50 Compare August 7, 2020 12:21
@mmontes11 mmontes11 force-pushed the generalize-gql-error-parsing branch from eaa9f50 to 27765f9 Compare August 7, 2020 12:22
Copy link
Contributor

@mislav mislav left a comment

Choose a reason for hiding this comment

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

This looks perfect! Thank you so much for following through with all the updates 🙇

@mislav mislav merged commit 23337e0 into cli:trunk Aug 10, 2020
@mmontes11 mmontes11 deleted the generalize-gql-error-parsing branch August 10, 2020 15:40
@vilmibm vilmibm added this to Backlog 🗒 in The GitHub CLI via automation Aug 13, 2020
@vilmibm vilmibm moved this from Backlog 🗒 to Pending Release 🥚 in The GitHub CLI Aug 13, 2020
@github-actions github-actions bot moved this from Pending Release 🥚 to Done 💤 in The GitHub CLI Sep 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
The GitHub CLI
  
Done 💤
Development

Successfully merging this pull request may close these issues.

"json: cannot unmarshal string" error message for unsuccessful "gh api" request
3 participants