search

neos / neos-development-collection

The unified repository containing the Neos core packages, used for Neos development.
https://www.neos.io/
GNU General Public License v3.0
260 stars 218 forks source link

BUG: Discarded node remains in cache if UI was reloaded between creation and discard #5150

Closed grebaldi closed 1 week ago

grebaldi commented 1 week ago

I've encountered some weird occasions in which the content cache becomes stale after discarding.

For example:

If I create a content node and then immediately discard it, the node remains cached:

https://github.com/neos/neos-ui/assets/2522299/edb77745-e3d5-4fb7-86a2-0be4145485bd

If I create a content node, then edit its properties and immediately discard it, the node vanishes from cache (which is what should always happen):

https://github.com/neos/neos-ui/assets/2522299/309b0458-80ac-498e-a8cd-a21a7232c427

Now, weirdly, if I create a content node, then edit its properties, then reload the UI and discard it, the node remains cached:

https://github.com/neos/neos-ui/assets/2522299/2d6bb328-fa94-4915-93c3-b777a1fb8fb9

kitsunet commented 1 week ago

Is this an UI bug? or rather a backend bug? I guess the middle "correct" behavior is due to the change flushing the cache correctly and discarding it before rebuilding the cache entry will lead to it being gone from the cache.

grebaldi commented 1 week ago

@kitsunet

Is this an UI bug? or rather a backend bug?

Not sure. The fact that it happens when no PropertiesWereSet event occurs speaks for the backend. The fact that it also happens after reloading the UI speaks for the UI.

I guess the middle "correct" behavior is due to the change flushing the cache correctly and discarding it before rebuilding the cache entry will lead to it being gone from the cache.

Plausible, indeed. This would leave us with the backend being the culprit.

In theory, if I were to change a property in the inspector that causes a reloadIfChanged, I should then also see a stale cache entry after discard (because the node was re-rendered in between). I'll test this to see if your hypothesis holds.

EDIT: It does not :( But this could also be due to differences between regular fusion rendering and out of band rendering. So, your explanation is not ruled out.

EDIT 2: Found it. It's a regression introduced with https://github.com/neos/neos-development-collection/pull/5083, so definitely a backend thing. I'll move the issue.

mhsdesign commented 1 week ago

We do rely hard core on the fact that we create a new cache entry if we discard / publish or do any thing. Thats why we dont flush these affected nodes. Because we just render the stuff and let the cache entry get garbage collected if at all :D

before (after deleting Text Node in the middle of the document and rerendering:

  entries => array(2)
    string "70d69c77a4e9fef0fc86521f2682d7df" (32) => string "<div class="neos-contentcollection">[Text Node at the start of the document][Text Node in the middle of the document][Text Node at the end of the document]</div>" (161)
    string "73dff7036302d0d063a22b3e1190e0c3" (32) => string "<div class="neos-contentcollection">[Text Node at the start of the document][Text Node at the end of the document]</div>" (120)
  tagsAndEntries => array(4)
    string "DescendantOf_user-editor_default_test-document-with-contents--main" (66) => array(2)
      string "70d69c77a4e9fef0fc86521f2682d7df" (32) => true
      string "73dff7036302d0d063a22b3e1190e0c3" (32) => true
    string "DescendantOf_default_test-document-with-contents--main" (54) => array(2)
      string "70d69c77a4e9fef0fc86521f2682d7df" (32) => true
      string "73dff7036302d0d063a22b3e1190e0c3" (32) => true
    string "Node_user-editor_default_test-document-with-contents--main" (58) => array(2)
      string "70d69c77a4e9fef0fc86521f2682d7df" (32) => true
      string "73dff7036302d0d063a22b3e1190e0c3" (32) => true
    string "Node_default_test-document-with-contents--main" (46) => array(2)
      string "70d69c77a4e9fef0fc86521f2682d7df" (32) => true
      string "73dff7036302d0d063a22b3e1190e0c3" (32) => true

now

  entries => array(1)
    string "9f4f3ec0a51728a02c7a0db6cd33d87a" (32) => string "<div class="neos-contentcollection">[Text Node at the start of the document][Text Node in the middle of the document][Text Node at the end of the document]</div>" (161)
  tagsAndEntries => array(4)
    string "DescendantOf_user-editor_default_test-document-with-contents--main" (66) => array(1)
      string "9f4f3ec0a51728a02c7a0db6cd33d87a" (32) => true
    string "DescendantOf_default_test-document-with-contents--main" (54) => array(1)
      string "9f4f3ec0a51728a02c7a0db6cd33d87a" (32) => true
    string "Node_user-editor_default_test-document-with-contents--main" (58) => array(1)
      string "9f4f3ec0a51728a02c7a0db6cd33d87a" (32) => true
    string "Node_default_test-document-with-contents--main" (46) => array(1)
      string "9f4f3ec0a51728a02c7a0db6cd33d87a" (32) => true

The problem is even with the changes here https://github.com/neos/neos-development-collection/pull/5163 where we check the nodes that were discarded partially, if they were deleted we will never be able to calculate their parents and thus flush correctly the DescendantOf_default_test-document-with-contents--main tag.

These are the maximum information that are available. Everything that is local to the text-node-middle node. But no nodetypes or parents.

array(4)
 string "Node_user-editor_default_text-node-middle" (41) => string "which were tagged with "Node_user-editor_default_text-node-middle" because that identifier has changed." (103)
 string "DynamicNodeTag_user-editor_default_text-node-middle" (51) => string "which were tagged with "DynamicNodeTag_user-editor_default_text-node-middle" because that identifier has changed." (113)
 string "DescendantOf_user-editor_default_text-node-middle" (49) => string "which were tagged with "DescendantOf_user-editor_default_text-node-middle" because node "Node_user-editor_default_text-node-middle" has changed." (144)
 string "Everything" (10) => string "which were tagged with "Everything"." (36)

Places were we manifest this behaviour:

Ideas to solve this:

P.S. i deobfuscated my cache tags locally to not use sha1 for debugging so they are understandable, see https://github.com/neos/neos-development-collection/issues/5164