@custom resolver results in status code: 400

Hi, I try to test @custom resolvers. Here is my schema for dgraph:

type Query {
  test: String!
    @custom(
      http: {
        url: "http://localhost:8081/query"
        method: POST
        graphql: "query {test}"
      }
    )
}

On “http://localhost:8081/query” I have my 2nd GQL server running. The test query using only that server returns just fine.

But by using Dgraph I get "Evaluation of custom field failed because external request returned an error: unexpected status code: 400 for field: test within type: Query."

Any Idea where this might come from? Thanks!

Edit:
I think that this is indeed a Bug.

I am using latest dgraph server v20.07.2 shuri-2

Is your 2nd GQL server also a Dgraph instance? I am thinking this could be a missing content type header possibly.

No, it’s not a Dgraph instance. But good point, I’ll try with another Dgraph server and if that works I’ll dig deeper.

Okay, using another Dgraph instance I now get:

"message": "unable to parse media type: mime: no media type"

What headers are needed such that Dgraph can interpret the results correctly? Can I find documentation on that topic somewhere?

By the way, my GQL server is sending the content-type “application/json” so I guess that should be fine?

Do you maybe have a working setup? I still couldn’t find one and am a little bit stuck here.

I checked out the latest master, built dgraph from source and it seems like that the error is gone there!

What is the usual ETA to have master code included in stable releases?

Sorry, I have not had time to duplicate a custom graphql query yet.

Awesome! Glad the bug was already squashed!

This from what I have seen varies a lot. If it is a bug that is not a breaking change, sometimes it can be cherry picked into a minor release. If it is a breaking change or new feature then it will go into the next quarterly(?) release after it has been fully tested and merged. The next major release (20.11) is set for “early November” from what I have been informed on Discuss.

Are you using Slash GraphQL? If so, presenting a (not) working example of the issue may help.

I must admit that I’m fairly new to the Dgraph-game (3 days) so I do not fully understand the differences between your products. I’m using the binaries from www.dgraph.io/downloads and deploy them on my custom server. So I guess that’s not “Slash Graphql”? (I’ve seen that thiss some kind of one-click deployment-service?)

Anyhow, do you have any tips what strings I can pull or who I need to trigger such that this squashed bug will find its way into the next major release?

Sure, Slash is the fully managed DBaaS. Set yourself up with a free Slash Account: https://slash.dgraph.io/

You can deploy up to three instances on the free tier with a total monthly credit allowance of 10K.

This guide will walk you through any details you might need.

If I were you, I would setup two backends both on Slash and then setup a custom query from one to the other. Load in a few sample nodes of data and duplicate the problem. Once duplicated, open up a ticket on slash for support and they should be able to get into the logs to see what exactly is going on to pinpoint the bug and the fix.

@gja is your man for Slash support here on Discuss!

1 Like