Problem with render caching of Paragraph-referenced entities

Description:

We are experiencing caching issues when using Paragraphs containing entity references (to nodes in our case).
On the content type that contains a paragraph field, a paragraph could be added that provides an entity reference to nodes of another content type. When saving the paragraph-containing node, everything works as expected (node referenced via paragraph gets rendered, based on the paragraph display settings).

However, when the referenced node gets updated, the paragraph-containing node shows outdated information, when caching is enabled.

Debugging the cache tags, I noticed there is no cache tag on the paragraph-containing node that is linked to the referenced node, so its render cache does not get invalidated when the referencing node would change.

Steps to reproduce:

* Create basic content type (e.g. Page)
* Create Paragraph type, e.g. "Related content", which contains one entity_reference field, that is able to reference nodes of type 'page'.
* Create content type News
* Add Paragraphs field to CT News, allowing paragraphs of type "Related content"
* Configure paragraph display settings to use "Rendered entity" for the entity_reference field
* Enable Drupal core page_cache / dynamic_page_cache module, and make sure a real caching backend is used (e.g. DB caching)
* Create a page node with title "test" and body "version 1"
* Create a news node with a paragraph referencing node "test"
* View news node. It should show "version 1" on the paragraph field output.
* Edit node "test" and change body to "version 2"
* View news node. It still shows "version 1"

Context:

* Using Drupal 8.2.6
* Using latest releases of Paragraphs (1.1) and Entity Reference Revisions (1.2)

I currently fixed this with some custom code that uses hook_entity_build_defaults_alter() to add extra cache tags.
Basically it checks for existing paragraph fields that contain an entity_reference field.
If found, it adds the 'node:[NID]' tag for each referenced node.
Now the last step in the "Steps to reproduce" above contains the right information, instead of the outdated.

I have searched for an existing issue in the queue, but couldn't find one.
Any pointers on how this problem could be fixed (preferably without using custom code), or where patches would need to be applied to fix it, would be very much appreciated.

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment almost 2 years ago →
🇺🇸United States alphex Atlanta, GA USA
How many of you are on Pantheon?

I've built a few sites in the last year or two who rely on paragraphs HEAVILY for page building, and this symptom crops up every so often.

I'm testing this patch now on a production site, I'll follow up in a few days with any results.
Comment almost 2 years ago →
🇫🇷France fgm Paris, France
The site on which I had this run on a bare VM, and I could see the issue even on my native mac (no containers involved), so no Pantheon there.
Comment over 1 year ago →
🇺🇸United States alphex Atlanta, GA USA
Updating this ticket.

The patch in #19 hasn't done anything to make this better.

Just last night I got an alert in my page diff monitoring tool that something changed.

The larger red box on this image is a paragraph type that sits on a node.
And has 4 paragraphs inside of it.

The alert I got showed that the 4 sub paragraphs had vanished.

The only way to restore things when this happens is to edit the node, and simply change the weight of the elements that are impacted, and hit save.

This clears what ever problem is happening, and makes them show up again. (drush cr does nothing...)

No errors show up in watch dog related to this.
Comment 10 months ago →
🇺🇸United States vegantriathlete Lakewood, CO
This is an interesting approach to tackling this problem. It's a decent start. Here are the limitations I am seeing:

It makes heavy assumptions about using nodes. The entity references won't necessarily be limited to nodes; they could be to media or terms, for example. So, for media references, the cache tag would not be node:[nid], it would be media:[mid].

It appears to stop at one level and expects that you have a node that references a paragraph that has an entity reference. It's also possible that you could have nested paragraphs that ultimately have an entity reference field.

Finally, associating the cache tags with the node entity will cause the entire node view template to be invalidated. If I understand Drupal's caching and rendering properly, I thought it has the ability to invalidate just part of a page. It would be preferable to have the cache tags tied to the correct element / layer of the render array.

I'm going to continue thinking on this and see what I can do with hook_ENTITY_TYPE_entity_build_defaults_alter.