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

Graphql Error 200 #140

Closed
nicosampler opened this issue Jul 8, 2019 · 13 comments · Fixed by #618
Closed

Graphql Error 200 #140

nicosampler opened this issue Jul 8, 2019 · 13 comments · Fixed by #618

Comments

@nicosampler
Copy link

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
Copy link

jjant commented Jul 11, 2019

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

@Janiczek
Copy link

Janiczek commented Aug 7, 2019

@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
Copy link

jc4p commented Aug 21, 2019

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

@prabhugopal
Copy link

prabhugopal commented Jan 24, 2020

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
Copy link

gunar commented Mar 6, 2021

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
Copy link

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
Copy link

erkkah commented Dec 6, 2021

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
Copy link

omsharp commented Apr 12, 2022

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
Copy link

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
Copy link

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
Copy link

morgnism commented Jun 24, 2023

@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
Copy link
Collaborator

jonkoops commented Nov 5, 2023

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
Copy link
Member

@jonkoops Yep that would be great!

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 a pull request may close this issue.