-
-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: Discarded node remains in cache if UI was reloaded between creation and discard #5150
Comments
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. |
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.
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 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 #5083, so definitely a backend thing. I'll move the issue. |
The test scenario consists of a document with a main content collection that initially contains two simple text content nodes. During the scenario, we switch to a user workspace and insert a third text node between the two initial nodes. The test then verifies, that fusion renders all three text nodes in order. Afterwards we discard the change we just made and check whether fusion now stops rendering the discarded node. Confirming #5150, with this commit, said verification fails.
The test scenario consists of a document with a main content collection that initially contains two simple text content nodes. During the scenario, we switch to a user workspace and insert a third text node between the two initial nodes. The test then verifies, that fusion renders all three text nodes in order. Afterwards we discard the change we just made and check whether fusion now stops rendering the discarded node. Confirming #5150, with this commit, said verification fails.
The test scenario consists of a document with a main content collection that initially contains two simple text content nodes. During the scenario, we switch to a user workspace and insert a third text node between the two initial nodes. The test then verifies, that fusion renders all three text nodes in order. Afterwards we discard the change we just made and check whether fusion now stops rendering the discarded node. Confirming neos#5150, with this commit, said verification fails.
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
now
The problem is even with the changes here #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 These are the maximum information that are available. Everything that is local to the
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 #5164 |
The test scenario consists of a document with a main content collection that initially contains two simple text content nodes. During the scenario, we switch to a user workspace and insert a third text node between the two initial nodes. The test then verifies, that fusion renders all three text nodes in order. Afterwards we discard the change we just made and check whether fusion now stops rendering the discarded node. Confirming neos#5150, with this commit, said verification fails.
… nodes" Discarding individual nodes works through a separate command that still needs to be considered by the recently introduced cache invalidation mechanism in `WorkspaceProjectorCatchUpHookForCacheFlushing`. This commit introduces a test that illustrates the issue.
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:
Peek.2024-06-19.14-15.Discard.Bug.-.Behavior.without.Property.Changes.mp4
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):
Peek.2024-06-19.14-11.Discard.Bug.-.Desired.Behavior.mp4
Now, weirdly, if I create a content node, then edit its properties, then reload the UI and discard it, the node remains cached:
Peek.2024-06-19.14-13.Discard.Bug.-.Behavior.after.Reload.mp4
The text was updated successfully, but these errors were encountered: