Hotchocolate v14 Persisted Query Id - backwards compatibility option

[robbirdht]

Product

Hot Chocolate

Is your feature request related to a problem?

Apologies if I am missing something in the docs, the migration guide to v14, or just general graphql understanding.

I am seeing a breaking change with persisted queries in version 14 of HotChocolate and would love a simple way to override the way query Ids are managed to enable backwards compatibility. This would make upgrading easier and would not affect calling clients (which is a blocker to me for upgrading)

In v13 I am able to store persisted queries (in my case using filesystem) in a file say "query1.graphql".
Then issue the request:

{
  "id": "query1",
  "variables": {
    "somevar": 12345
  }
}

Upgrading to v14 this query now gets the response

{
    "errors": [
        {
            "message": "Invalid query id format."
        }
    ]
}

Is this expected? Reading the docs, the Id passed in by clients should be the query hash. But in my use case calling clients use specific named queries as above. So how if 13 is already in use and calling clients cannot be easily changed, how do I migrate?

The solution you'd like

Ideally some way to override this behaviour and implement the behaviour to map the query id passed in to a stored query (in my file storage example it would map to the file name).

If this is possible and I have missed it, then I guess I am asking for a change to the upgrade guide or persisted queries documentation to explain how.

[michaelstaib]

The ID you posted would still be valid. What actual value did you pass?

[robbirdht]

Ah, could this be because the name has invalid characters? Not sure why I didn't think of that sorry!

The value includes characters "(", ")" and "," i.e. "name(data1,data2,data2)"

Are there any characters that would be rejected through HotChocolate validation, but would be valid characters in a file name?

[michaelstaib]

Yes, we now validate the name for security reasons, as when you map the name 1:1 to a file it provides an attack vector. So, now we in the transport layer already reject names that do not fit the following: a-z A-Z 0-9 - _

Other characters are not allowed as an operation ID. There is also no way around this as we have now a typed operation id struct which ensures that it cannot even passed into the execution engine if it does not fit the pattern.

[robbirdht]

Thanks for explaining, this makes sense now.

I will have a think how to migrate people over to new names. Thanks for the quick responses.