@remote mutations/queries - how to return errors?

Hello,
given example in https://graphql.dgraph.io/doc/custom/mutation - when the api server returns error (“record already exists”), how can I pass it to the caller?
If the result is not in expected format, the caller gets:

  "errors": [
    {
      "message": "Non-nullable field 'id' (type ID!) was not present in result from Dgraph.  GraphQL error propagation triggered.",
...}]}

Is it possible to return error messages (from the API) so they could be passed to the caller? If so, how to do it?

1 Like

There is no way at present to do that. There have been similar queries previously too. The problem with this is that different APIs return errors in innumerously different ways, and we don’t know apriori that what is the error format an API is going to return. Some, just work with HTTP status codes, some give errors in body directly as string, some give errors as JSON, and what not.

But, can you give us an example of how your API returns errors and how you would want to see that in GraphQL response? That would help us jot down all possible ways of returning errors from APIs, and maybe in future we will try to support the one, which we find to be used by a lot of people.

++ @JatinDevDG

1 Like

I can modify my API (i think this is the case anyways if one is going to use the API as @remote dgraph endpoint), I was expected that for example if I return list of error strings (as in Errors []string 'json:“errors”’`), the GraphQL layer would pass it to the client (possibly appending its own error entry).
So for example:
api.internal returns:

 {"errors": [{"message": "Record already exists."}]}

then GraphQL returns:

{
 "errors": [
    {
      "message": "Record already exists."
    },
    {
      "message": "Non-nullable field 'id' (type ID!) was not present in result from Dgraph.  GraphQL error propagation triggered.",
...}]}
2 Likes

This is my thought as well. Support one way (I like errors property in returned json) and then users will have to adjust their APIs to match. Most of these APIs will be custom built to support their dgraph setup anyways.

Another thought is that most of these APIs will probably end up being lambda functions (at least that is my setup) I see that Dgraph also uses AWS to host Slash, it would be neat if eventually Slash supported integrated functions.

Netlify does this with their front end deployments allowing users to build their backend scripts right next to their front end UI. This would make sense in dev writing functions right next to my schema, and could also possibly help generate some more revenue for dgraph SaaS.

1 Like

We now have support to return error array from custom query and fields. This changed was merged last month, forgot to mention here. PR: Feat(GraphQL): This PR allows to return errors from custom REST endpoint. by JatinDevDG · Pull Request #6604 · dgraph-io/dgraph · GitHub

2 Likes