https://kotlinlang.org logo
Title
a

agrosner

04/05/2022, 7:31 PM
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
the solve would be to try to override the
operationIdGenerator
to match the way the safelisting generation works
mapOf(
              "signature" to document.safelistingHash(),
              "document" to document
          )
in RegisterOperations.kt
m

mbonnin

04/05/2022, 8:31 PM
I'm confused. APQ and safelisting do not have to use the same hashes. Is that the problem?
Im no server expert but my understanding is that they have completely different paths on the server
So it should be fine to have one hash for APQ and a different one for safelisting
a

agrosner

04/06/2022, 1:12 PM
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?
or am i misunderstanding how safelisting works
m

mbonnin

04/06/2022, 6:30 PM
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?
Are you getting a specific error? Maybe we can start from there?
a

agrosner

04/06/2022, 7:27 PM
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:”
🙌 1
the server was injecting the
__typename
always into our query, while FE was not. by upgrading and using the
always
option, it fixed
m

mbonnin

04/06/2022, 7:29 PM
Oh the server adds
__typename
when computing the hash?
a

agrosner

04/06/2022, 7:36 PM
sorry, our server tool that runs apollo register for us. the server was doing the right thing
m

mbonnin

04/06/2022, 7:36 PM
Ahh yea gotcha 👍
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
With
registerOperations
, you're guaranteed that the input to the hashing algorithm is matching 100% what Apollo Kotlin is sending over the wire
s

Sam Michael

04/06/2022, 7:39 PM
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
m

mbonnin

04/06/2022, 7:40 PM
I see...
Does your register tool run in Github actions by any chance?
s

Sam Michael

04/06/2022, 7:40 PM
It is a Node Package that wraps over Apollo CLI i believe
m

mbonnin

04/06/2022, 7:40 PM
If they can run Kotlin you can register without Gradle pretty easily
Ah yea... They're most likely not super keen on installing a JVM + Kotlin then I guess?
I was thinking I could send you a small
register.main.kts
script that takes the Gradle plugin logic and that could run anywhere
Github actions has Kotlin installed by default so it's pretty convenient
s

Sam Michael

04/07/2022, 1:00 PM
@agrosner cc thanks Martin we should look into some alternative if there is still a danger of mismatches even with 'always' config.
m

mbonnin

04/07/2022, 1:45 PM
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"
:thank-you: 1