- Issue created by @pwolanin
- 🇳🇿New Zealand quietone
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .
The node module has very old code to add a cache context for the current user's node access grants inside a query alter.
This was added in #2557815: Automatically bubble the "user.node_grants:$op" cache context in node_query_node_access_alter() →
The goal is obviously to not cache and re-use a query result for a user with different node access grants to avoid information disclosures.
However, the way it's accomplished is using the renderer to render an array with just cache metadata based on wether the current request represents a cachable page. Per @catch, this was "a kludge 10 years ago (along with one or two others) to unblock dynamic_page_cache and big_pipe".
A further reflection of the problem is that for REST plugins you have to execute all your node, etc. queries in a render context so that your REST response data has the correct cache metadata.
In core there should be a mechanism to add cache metadata (e.g. cache contexts or tags) to Select and Entity queries and core should handle adding that cache metadata as part of the cache context for the current response if needed.
Possibly this should take the form of adding a callback instead of the actual data since in the current node module implementation we avoid calculating the user's node access grants if the request is not going to be cached.
This is a little tricky since we don't know what happens to the data once the query is executed, so possibly you'd have to handle this in the execute() method. That also seems like a kludge.
Decide on the architecture including how this data is added to a query and where core is going to collect the data
Define on a mechanism other than calling the renderer to add cache data. This need to handle
Change the way the query systems interact with the cache system, TBD
Active
11.1 🔥
cache system
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → .