I am currently trialling this with PWA studio with using @apollo/client/link/persisted-queries https://www.apollographql.com/docs/react/api/link/persisted-queries/

Contrary to the documentation here

in my trials the client on the missed hash response does resend the query but never includes the hash. Not sure if this is an outdated graphic or something undocumented in the apollo client.

Currently simply having the server always create the hash seems to work better

    public function afterDispatch(
        GraphQl $subject,
        ResponseInterface $result,
        RequestInterface $request
    ): ResponseInterface {
        $data = $this->getDataFromRequest($request);

        if (!isset($data['query'])) {
            return $result;
        }

        $cacheKey = $this->getCacheKeyFromQueryHash(hash('sha256', $data['query']));
        if ($this->cache->load($cacheKey) === false) {
            $this->cache->save($data['query'], $cacheKey, [Apq::CACHE_TAG]);
        }

        return $result;
    }

Keen to hear if you are seeing something different.

Magento's GraphQl unfortunately uses a custom header to differentiate store views. For the moment just adding the testcase here to document as I am not sure at what stage this should be best solved (frontend client, apollo automatic persisted queries or here). There is also a related dimension to the currency or Authorisation header (as for example logged in users might get a different price based on customer group).

I have previously trialled converting the custom header to /graphql?store='store_view_code&query={...}' but I believe that is still not very aligned with how graphql is most commonly used and might still require a custom hash function in the frontend https://github.com/apollographql/apollo-client/blob/main/src/link/persisted-queries/index.ts#L112

Hi. I think I found a quite huge bug which I cannot really explain to myself how it's happening. If this module is enabled and I request a category via the categories query, the category doesn't have an id if requested as persisted query. If I request the category normally, without the usage of persisted queries, everything works fine.

This leads to some problems, for example in when requesting the category canonical field. In the resolver for the field the function getUrl is executed.

The function getUrl tries to retrieve a rewrite as seen here. It cannot find an entry as at this point the id of the category is not set which will lead to the function getCategoryIdUrl (directly below) which then returns catalog/category/view/ without the id as it's not set of course.

In the variable $value in resolvers the id is set ($value['id']), but not in $value['model'] where the corresponding model resides.

I have no idea how this problem occurs, but it definitly only occurs when using persisted queries via this module. And only for categories, for products everything is working as it should.

@danslo Do you have any idea why this happens?

Use https://github.com/extdn/github-actions-m2 to add integration tests.

Ensure:

• Persistent query not found with POST: status 500.
• Persistent query not found with GET: status 400.
• Query is cached.
• SHA256 does not match: status 405 and body provided sha does not match query.

Typical request chain when cache is not warm:

1. Get query with persistent query hash only [PERSISTED_QUERY_NOT_FOUND]
2. POST query with persistent query hash and query.
3. GET query with persistent query hash only.
4. GET query with persistent query hash only.
5. GET query with persistent query hash only.
6. etc...

Currently we only get a X-Magento-Cache-Debug: HIT on the 4th request forward. It should be possible to do this on the 3rd request by tinkering with FPC in 2nd request.

Cover it with tests.