Persisted Query Hashed don't match with Fragments

[alexnsorensen]

Hi all

I have a weird issue happening, when using URQL and persisted queries with fragments, and I want to make sure I'm using it correctly.

If I follow the instructions here:
https://commerce.nearform.com/open-source/urql/docs/basics/core/#graphql-tags

Then I have my code like this (using the demo):
import { gql } from '@urql/core';

const TodoFragment = gql`
  fragment SmallTodo on Todo {
    id
    title
  }
`;

const TodosQuery = gql`
  query {
    todos {
      ...TodoFragment
    }
  }

  ${TodoFragment}
`;

When I run my codegen to generate hashes, I might get this c727a2c5 (using a fake hash for demonstration), then when urql runs, it would send this hash 701e6878, and what's caused this seems to be one (or more) of these:

1. Codegen moves the fragments to the start of the query
2. The above way of merging gql queries moves fragments to the end of the query

so Codgen is producing:

{
    "c727a2c5": "fragment SmallTodo on Todo {\n  id\n  title\n}\nquery {\n  todos {\n    ...TodoFragment\n  }\n}"
}

and urql is sending this (once it sends the incorrect hash it sends the full query):

query {\n  todos {\n    ...TodoFragment\n  }\n}\nfragment SmallTodo on Todo {\n  id\n  title\n}

But if I do this:

import { gql } from '@urql/core';

const TodosQuery = gql`
  fragment SmallTodo on Todo {
    id
    title
  }
  query {
    todos {
      ...TodoFragment
    }
  }
`;

Then the hashes are correct and match, and the persisted query is used.

Am I not using this correctly?

[JoviDeCroock]

I would say that the issue is the difference in how your PO aggregator shifts the order of the query 😅 I haven't really seen that before, the GraphQL Code Generator client-preset attaches a __HASH__ property to the generated AST you can use in the persisted-fetch exchange so you don't run into these problems, a little post about that

[kitten]

fwiw, the order should be respect by code gen imho and it's likely just stitching the documents together in reverse order.
What code gen tool are you running?

You'll have to likely normalise your document or get it to match the document if you do care about these matching. But usually, in production, it's common to leave the documents out entirely and to use your codegen's query to populate the API with what the query stand for (which is fine since they're functionally equivalent of course)

[JoviDeCroock]

Yes, but if OP relies on it being hashed by the persisted exchange it will cause a mismatch so I feel it's safer to rely on the generated hash attached to the document or at least the same tool doing normalisation + hashing

[alexnsorensen]

Sorry for the slow reply guys, been very busy I have tried both of these:

https://the-guild.dev/graphql/codegen (client preset)
https://www.npmjs.com/package/graphql-codegen-persisted-query-ids