Skip to content

Response errors should result in a Left of error#578

Merged
nalchevanidze merged 1 commit intomorpheusgraphql:masterfrom
AlistairB:response-errors
Sep 20, 2021
Merged

Response errors should result in a Left of error#578
nalchevanidze merged 1 commit intomorpheusgraphql:masterfrom
AlistairB:response-errors

Conversation

@AlistairB
Copy link
Copy Markdown
Contributor

Even when the response a can still be successfully parsed.

Closes #577

processResponse JSONResponse {responseData = Just x} = Right x
processResponse JSONResponse {responseData = Just x, responseErrors = Nothing} = Right x
processResponse JSONResponse {responseData = Just x, responseErrors = Just []} = Right x
processResponse invalidResponse = Left (show invalidResponse)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

what do you think, maybe we can use JSON "decode" instead of regular show?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

will provide easier understandable error messages.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

So you might do something like:

      processResponse JSONResponse {responseData = Just x, responseErrors = Nothing} = Right x
      processResponse JSONResponse {responseData = Just x, responseErrors = Just []} = Right x
      processResponse JSONResponse {responseErrors = err} = Left $ decodeUtf8 $ encode err

but you can't do

     processResponse invalidResponse = Left $ decodeUtf8 $ encode invalidResponse

As JSONResponse has an a and based on the Fetch typeclass we don't know that we have ToJSON a constraint. So you would need to either add the ToJSON a constraint, which maybe the user doesn't want to provide. Or exclude the responseData from the error message.

Based on this issue I think the current implementation is fine. Also, I think unless you prettify the json, a json error message is not too different to a show error message. What do you think?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

If you wanted to improve this more, I think the right solution would be to have fetch return a m (Either FetchFailure a) where (roughly sketched)

data FetchFailure = 
  FetchConnectionIssue String
  | ResponseDecodeFailure String
  | ServerGQLErrors (NonEmpty GQLError)
  deriving (Show, ToJSON)

This gives the user structured data they can work with if they want, or they can just show / render to JSON. I'd suggest this be done as a separate issue/PR though.

@nalchevanidze
Copy link
Copy Markdown
Member

nalchevanidze commented Feb 2, 2021

@AlistairB thanks, i leaved some comments. they are proposals, but if you think same way, we could implement them.

@AlistairB
Copy link
Copy Markdown
Contributor Author

@nalchevanidze I've done 2/3 and left some comments on the other suggestion. Let know what you think. Thanks.

@AlistairB AlistairB force-pushed the response-errors branch 2 times, most recently from 3bdea10 to fa72731 Compare March 21, 2021 06:47
@AlistairB
Copy link
Copy Markdown
Contributor Author

AlistairB commented Mar 21, 2021

@nalchevanidze I had a bit of time so I thought I'd implement something like #577 (comment)

The missing piece is even though the GQLError is returned, it doesn't include arbitrary fields in the error response. ie.

{
  "data": {
    "repository": null
  },
  "errors": [
    {
      "type": "NOT_FOUND",
      "path": [
        "repository"
      ],
      "locations": [
        {
          "line": 7,
          "column": 3
        }
      ],
      "message": "Could not resolve to a Repository with the name 'facebook/reacttt'."
    }
  ]
}

I'd like to be able to get the type field somehow.

I think to do this I'd like to update GQLError to be include arbitrary fields included in the response. However, this type is used through the various packages. I'd probably instead have something like:

data FetchGQLError = FetchGQLError {
  fetchError :: GQLError,
  rawError :: HashMap Text Value
}

When you aren't busy with your thesis, I'm curious what you think of what I have implemented and this addition. Thanks

(I'll probably have a crack at this addition in a week or so)

@AlistairB AlistairB force-pushed the response-errors branch 2 times, most recently from 90fe2a2 to 7086bf5 Compare May 14, 2021 06:35
@AlistairB
Copy link
Copy Markdown
Contributor Author

AlistairB commented May 14, 2021

@nalchevanidze I have updated the PR based on #577 (comment) . The only difference is I added another case to FetchError of FetchErrorNoResult where you get no a but also there are no errors. Let me know what you think 🙂

Oh I also updated the stackage to use the latest LTS, I can revert if you want.

EDIT: This PR does not solve the problem of exposing additional custom fields in the errors, but I think that should be addressed with a separate PR.

nalchevanidze
nalchevanidze previously approved these changes Sep 13, 2021
@nalchevanidze
Copy link
Copy Markdown
Member

@AlistairB sorry for long delay . there is some merge conflicts when you resolve them feel free to merge it (is approved!).

yeah. would be great if you could also update change-log :)

Copy link
Copy Markdown
Contributor Author

@AlistairB AlistairB left a comment

Choose a reason for hiding this comment

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

Thanks for the approval @nalchevanidze . I have rebased and updated this PR.

There was one area I was uncertain about which I have left a comment. Also the tests for morpheus-graphql-app are failing in master, but otherwise I think everything is passing. (And the Deploy Docs build is failing, apparently unrelated to the changes).

Even when the response `a` can still be successfully parsed.

Add a new `FetchError` type to cover all the possible fetch failure
scenarios.
@nalchevanidze nalchevanidze merged commit da5bb4a into morpheusgraphql:master Sep 20, 2021
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.

[client] response errors sometimes not made available

2 participants