hey related to my colleague <@U027BK2LMBP> questio...

# apollo-kotlin

[agrosner]

hey related to my colleague @Sam Michael question here
we are running into the mismatch issue which seems a bit more troubling. since the hashing algorithm by default will generate a query hash exactly on how the query is done, immediately there is a mismatch between that has for APQ and operation safelisting. If the query keys are not alphabetically sorted with __typename first, the two hashes used will never match up

[agrosner]

the solve would be to try to override the operationIdGenerator to match the way the safelisting generation works

[agrosner]

mapOf(
              "signature" to document.safelistingHash(),
              "document" to document
          )

in RegisterOperations.kt

[mbonnin]

I'm confused. APQ and safelisting do not have to use the same hashes. Is that the problem?

[mbonnin]

Im no server expert but my understanding is that they have completely different paths on the server

[mbonnin]

So it should be fine to have one hash for APQ and a different one for safelisting

[agrosner]

right, maybe what im asking is that since safelisting changes the query sent up by normalizing it, wouldnt that break the client implementation sending the wrong query to the API?

[agrosner]

or am i misunderstanding how safelisting works

[agrosner]

https://github.com/apollographql/server-plugin-operation-registry/blob/fbf727003ba[…]5c4a88579c04b38bf91e/src/ApolloServerPluginOperationRegistry.ts
so i see it normalizes the query for you on the server

[mbonnin]

I'm no safelisting expert but I'd say safelisting is only used for validation of the query. The actual query being executed is the one sent by the client?

[mbonnin]

Are you getting a specific error? Maybe we can start from there?

[agrosner]

actually thank you for your help. it was all related to https://github.com/apollographql/apollo-kotlin/releases/tag/v3.2.0 with addition “In addition, it introduces a addTypename Gradle option to have better control over when to add the __typename field:”

[agrosner]

the server was injecting the __typename always into our query, while FE was not. by upgrading and using the always option, it fixed

[mbonnin]

Oh the server adds __typename when computing the hash?

[agrosner]

sorry, our server tool that runs apollo register for us. the server was doing the right thing

[mbonnin]

Ahh yea gotcha 👍

[mbonnin]

I'd strongly recommend using the registerOperations Gradle task though as even with addTypename = "always" , there might be some discrepencies between what apollo-kotlin is doing and what apollo-cli is doing

[mbonnin]

With registerOperations , you're guaranteed that the input to the hashing algorithm is matching 100% what Apollo Kotlin is sending over the wire

[Sam Michael]

Thanks, yes we are working on convincing our graphql team to allow us a way to use API key since currently we do not have permission

[mbonnin]

I see...

[mbonnin]

Does your register tool run in Github actions by any chance?

[Sam Michael]

It is a Node Package that wraps over Apollo CLI i believe

[mbonnin]

If they can run Kotlin you can register without Gradle pretty easily

[mbonnin]

Ah yea... They're most likely not super keen on installing a JVM + Kotlin then I guess?

[mbonnin]

I was thinking I could send you a small register.main.kts script that takes the Gradle plugin logic and that could run anywhere

[mbonnin]

Github actions has Kotlin installed by default so it's pretty convenient

[Sam Michael]

@agrosner cc thanks Martin we should look into some alternative if there is still a danger of mismatches even with 'always' config.

[mbonnin]

Hopefully that won't be needed 🤞 But it's hard to tell 100% due to the different codebases. If you ever witness a mismatch, let us know and we can maybe add addTypename = "sameAsApolloCli"