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

1.3.2 - Wrong \n hash with persistent queries #3162

Closed
WolframPRO opened this issue Jul 31, 2023 · 1 comment · Fixed by #3163
Closed

1.3.2 - Wrong \n hash with persistent queries #3162

WolframPRO opened this issue Jul 31, 2023 · 1 comment · Fixed by #3163
Assignees
Labels
bug Generally incorrect behavior

Comments

@WolframPRO
Copy link

Summary

It looks like the hash for persistent requests hashes \n as two characters. But by default on the backend, this character is hashed as a single character. Due to a hash mismatch, the backend rejects any request

Version

1.3.2

Steps to reproduce the behavior

  1. Turn on persistent queries
  2. Send any query with fragment

Logs

Query:
{
  "extensions": {
    "persistedQuery": {
      "sha256Hash": "536acf1071fce858f0ccb1def84d13ddc4d60f0ceb7a72b711f7f1c3bfc0392f",
      "version": 1
    }
  },
  "operationName": "PhoneCountriesList",
  "query": "query PhoneCountriesList { system { __typename phoneCountries { __typename ...UPhoneCountry } } }\nfragment UPhoneCountry on PhoneCountry { __typename code phoneCode englishName nativeName }"
}

Responce:
{
  "errors": [
    {
      "message": "Wrong hash was passed"
    }
  ]
}
Right hash:
64a17fdeb09cbed60e07b1d7ac4f46da17ab0d98e22fa6adbf9e2d18c57fc58d

Anything else?

No response

@WolframPRO WolframPRO added bug Generally incorrect behavior needs investigation labels Jul 31, 2023
@BobaFetters
Copy link
Member

Thanks for reporting this, will take a look into today

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Generally incorrect behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants