Graphql Error 200

[nicosampler]

Hi I have a graphql server already running where I can run queries through graphiQL.

If I took one of those queries and run it from my nodejs script using this lib, it fails in a strange manner because it throws a 200 error, but the response contains the correct query response.

let me put an example, in graphiQL, if I run this:

{
  transfers(first: 1) {
    id    
  }
}

it responds with

{
  "data": {
    "transfers": [
      {
        "id": "0xf4e41c8eea5de765c86bcc0e1c87ced1d2de24ec6cab2add8cb12a3f4e8488d9-28"
      }
    ]
  }
}

but using this lib from my script

const query = /* GraphQL */ `
    {
      transfers(first: 2) {
        value
      }
    }
  `;

  request(graphUrl, query).then(console.log);

it responds

(node:3768) UnhandledPromiseRejectionWarning: Error: GraphQL Error (Code: 200): {"response":{"error":"{\"data\":{\"transfers\":[{\"id\":\"0xf4e41c8eea5de765c86bcc0e1c87ced1d2de24ec6cab2add8cb12a3f4e8488d9-28\"}]}}","status":200},"request":{"query":"\n    {\n      transfers(first: 1) {\n        id\n      }\n    }\n  "}}
    at GraphQLClient.<anonymous> (C:\Users\Lenovo\develop\subgraph-erc20-test\node_modules\graphql-request\dist\src\index.js:116:35)
    at step (C:\Users\Lenovo\develop\subgraph-erc20-test\node_modules\graphql-request\dist\src\index.js:40:23)    at Object.next (C:\Users\Lenovo\develop\subgraph-erc20-test\node_modules\graphql-request\dist\src\index.js:21:53)
    at fulfilled (C:\Users\Lenovo\develop\subgraph-erc20-test\node_modules\graphql-request\dist\src\index.js:12:58)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:3768) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with
.catch(). (rejection id: 1)
(node:3768) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise
rejections that are not handled will terminate the Node.js process with a non-zero exit code.

[jjant]

Same here! Trying to use TheGraph's API. It has the content-type header correctly set to application/json.

[Janiczek]

@nicosampler @jjant I hit this issue too, adding Content-Type: application/json header to the response from my GraphQL server helped.

It seems like here: https://github.com/prisma/graphql-request/blob/master/src/index.ts#L119-L126 If there's no Content-Type, the function returns response.text, and then later when handling the result the code tries to do: https://github.com/prisma/graphql-request/blob/master/src/index.ts#L32-L34 result.data ... that must fail, right?

[jc4p]

Add a Accept: application/json header to your client and it will hopefully get the server to set the response type for you

[prabhugopal]

Add a Accept: application/json header to your client and it will hopefully get the server to set the response type for you

Thanks @jc4p we too had the same issue. Adding the header value "Accept: application/json" resolved the issue.

Note :- Adding the "Content-Type: application/json" to the header didn't help us.

On a side note we should be better capturing the parse error or proper content error instead capturing the data inside error block, which confuses us more.

[gunar]

If you have an endpoint working as a proxy between the client and the graphql server, make sure you return

{ data: { … } }

and not just

{ … }

[micheljung]

In my case, the server (Smallrye GraphQL) responds:

content-type: application/graphql+json; charset=UTF-8

Solved by:

request(endpoint, query, variables, {accept: "application/json"})

[erkkah]

Hi! I know this spec is a work in progress: https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md#response, but it seems like a good idea to handle responses typed application/graphql+json, since the service is free to respond with a 406 Not Acceptable to the suggested workaround.

[omsharp]

I'm facing the same issue while working on file upload, and nothing worked. My server is returning "Content-Type: application/json" which, I think, is the right type. Tried setting "Accept: application/json" on request, but it's not working either.

The weird part is that everything works fine, the file is uploaded to server, and I've checked the JSON returned in the response and it's in the right format!

[andysteadbbc]

If you have an endpoint working as a proxy between the client and the graphql server, make sure you return

{ data: { … } }

and not just

{ … }

This worked for me. We were using nock to test responses and we were missing this in our object!!!!

[barayuda]

In my case, the server (Smallrye GraphQL) responds:

content-type: application/graphql+json; charset=UTF-8

Solved by:

request(endpoint, query, variables, {accept: "application/json"})

save my hours time, thanks @micheljung 🎉

[morgnism]

@nicosampler @jjant I hit this issue too, adding Content-Type: application/json header to the response from my GraphQL server helped.

It seems like here: https://github.com/prisma/graphql-request/blob/master/src/index.ts#L119-L126 If there's no Content-Type, the function returns response.text, and then later when handling the result the code tries to do: https://github.com/prisma/graphql-request/blob/master/src/index.ts#L32-L34 result.data ... that must fail, right?

Added this to my proxied route's response header worked. graphql-request seems to think that the stringified body returned by the response is text/plain.

[jonkoops]

Looks like the specification now stipulates the following for the Accept header:

It is RECOMMENDED that a client set the Accept header to application/graphql-response+json; charset=utf-8, application/json; charset=utf-8.

Considering this, and the fact that a next major version is due soon. Perhaps this should be included by default for every request made by graphql-request. @jasonkuhrt WDYT?

[jasonkuhrt]

@jonkoops Yep that would be great!