Some queries failing when using @urql/core version 1.16.1

[jonkoops]

Steps to reproduce

• Clone https://github.com/amsterdam/atlas
• Check out urql-repro branch
• npm i
• npm run start
• Open http://localhost:3000/datasets/zoek/

Expected behavior All calls to the GraphQL succeed

Actual behavior Not all GraphQL calls succeed

This problem seems to have been introduced in https://github.com/FormidableLabs/urql/pull/1225. We downgraded the dependency in our lockfile in our project and this seemed to resolve the issue.

[kitten]

Hiya :wave: Just before we go ahead and try to repro this by cloning the whole repo, can you give us some more information on the GraphQL errors or specific error behaviour you're seeing please? Like, an error message, whether it's the API that returns it, whether it's an error from graphql.js, etc.

[jonkoops]

Hi @kitten, sure I can provide you with some more information. We are making a GraphQL call which ends up in a server error due to a missing argument:

When we run this specific query on the older version (like our production environment) it seems to come trough ok. The following request body is sent there:

{
  "query": "query totalCountSearch($q: String!, $limit: Int) {\n  datasetSearch(q: $q, input: {limit: $limit}) {\n    totalCount\n    __typename\n  }\n  dataSearch(q: $q, input: {limit: $limit}) {\n    totalCount\n    __typename\n  }\n  articleSearch(q: $q, input: {limit: $limit}) {\n    totalCount\n    __typename\n  }\n  publicationSearch(q: $q, input: {limit: $limit}) {\n    totalCount\n    __typename\n  }\n  specialSearch(q: $q, input: {limit: $limit}) {\n    totalCount\n    __typename\n  }\n  collectionSearch(q: $q, input: {limit: $limit}) {\n    totalCount\n    __typename\n  }\n  mapSearch(q: $q, input: {limit: $limit}) {\n    totalCount\n    __typename\n  }\n}\n",
  "operationName": "totalCountSearch",
  "variables": {
    "q": ""
  }
}

However after upgrading it seems an entirely different query is executed:

{
  "query": "query datasetSearchQuery($q: String, $limit: Int, $page: Int, $filters: [FilterInput!], $withPagination: Boolean!) {\n  datasetSearch(q: $q, input: {limit: $limit, page: $page, filters: $filters}) {\n    ...DatasetFields\n    ...FilterFields\n    ...PageInfoFields\n    __typename\n  }\n}\n\nfragment DatasetFields on DatasetSearchResult {\n  totalCount\n  results {\n    header\n    teaser\n    modified\n    id\n    tags\n    distributionTypes\n    __typename\n  }\n}\n\nfragment FilterFields on SearchResult {\n  filters {\n    type\n    label\n    filterType\n    options {\n      id\n      label\n      count\n      __typename\n    }\n    __typename\n  }\n}\n\nfragment PageInfoFields on SearchResult {\n  pageInfo @include(if: $withPagination) {\n    hasLimitedResults\n    hasNextPage\n    totalPages\n    __typename\n  }\n}\n",
  "operationName": "datasetSearchQuery",
  "variables": {
    "q": ""
  }
}

The code that executes this query can be found here. The GraphQl queries are loaded through a WebPack loader and can be found here.

It looks like somehow the schema that goes in is transformed and a different query comes back than before.

[JoviDeCroock]

I tried reproducing it here, the query you see in this file is the one from your build output so I'm not really sure what is happening but for me it dispatches the same query in both versions https://codesandbox.io/s/thirsty-frost-cc9re?file=/src/index.js

EDIT: I guess this could be considered a bug in graphql-tag/loader, what they do is they attach the whole .gql document as node.loc.source.body.

[JoviDeCroock]

@jonkoops I've tried with the test-build of https://github.com/FormidableLabs/urql/pull/1316 which now seems to dispatch the right query, didn't get a result back due to a CORS issue with the GraphQL server but the issue itself seems resolver. We can publish this next week.

If you want to test this our yourself check the codesandbox-ci step and copy the link address of '@urql/core' there. Then add a resolutions key to your package.json that maps @urql/core to this url.

[jonkoops]

@JoviDeCroock thanks for giving it a test, I will also take a look and see if this resolves the issue.

[ibash]

I hit the same problem (incorrect request being made after using graphql loader) and tested this change locally. The fix worked on my codebase, any chance it can be published?

[JoviDeCroock]

Published on latest

[jonkoops]

Nice, I can confirm this indeed fixes the problem for us as well.