Circular dependencies in EntityReferenceRevisionsFieldItemList::hasAffectingChanges();

Created on 12 March 2019, almost 6 years ago
Updated 19 November 2023, about 1 year ago

We found an issue with EntityReferenceRevisionsFieldItemList::hasAffectingChanges()

We have a structur like this:

Node A -> Paragraph -> Node B -> Paragraph -> Node C -> Paragraph -> Node B

As you can see there is a circular dependency between Node B and Node C. So when we try to save Node A we get stuck in a infinite loop due to hasAffectingChanges() calling hasTranslationChanges() which in return calls hasAffectingChanges().

I have created a simple patch that works for us, but I don't think it's the correct solution. My guess is that hasAffectingChanges() should check what kind of field it is before going deep down in the rabbit hole to find entities with affecting changes. But I don't have the knowledge needed to fully understand what this method is supposed to do, and why.

πŸ› Bug report
Status

Needs work

Version

1.6

Component

Code

Created by

πŸ‡ΈπŸ‡ͺSweden logaritmisk

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

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

  • Hello, here is a new patch, it's work for me, I wanted to run the unit tests but there is always some missing dependences

  • I updated my patch. I kept the cache idea from @rabithk but I turn it into a stack to clear the cache out of recursion case.

  • First commit to issue fork.
  • Pipeline finished with Failed
    2 months ago
    Total: 341s
    #303721
  • Pipeline finished with Failed
    2 months ago
    Total: 169s
    #303738
  • πŸ‡©πŸ‡°Denmark kasperg

    I have tried to create a merge request for the change with an attempt to reset the static cache on save. I thought that this would address kernel tests breaking or other scenarios where the same entity is saved multiple times in the same request. Alas that did not prove to be the case.

    I based the merge request on the work in #2. It still applies, had the original feedback from Berdir and because I could not tell what the intention between this and the changes in #7 + #8 actually are.

Production build 0.71.5 2024