Recursion loop if default paragraph type is a nested type that has itself as default value

Does this really happen? I cannot reproduce, where does it "boom" exactly? when saving or when editing/viewing a node?

We could also simply disallow adding the own type as child again?

I tried @miro_dietiker proposal and seems like works, but test failing.

Just to check what tests will say.

Maybe I got this wrong, but isn't this only a problem with nested ones? So shouldn't we check if current and parent are nested?

I forgot to fix this for classic paragraphs.This is working pretty fine for me, hope it is a good approach.

I think this looks pretty fine, didn't test though. Some small doc things.

1. +++ b/src/Plugin/Field/FieldWidget/InlineParagraphsWidget.php
   @@ -766,7 +766,7 @@ class InlineParagraphsWidget extends WidgetBase {
   +      if ($default_type && $default_type != $items->getEntity()->bundle()) {
   ...
          // Checking if default_type is not none and if is allowed.
   ...
   +      if ($default_type && $default_type != $items->getEntity()->bundle()) {
   

   This seems fine, but this extra check is so much important, you should add a comment here why...

2. +++ b/src/Tests/Classic/ParagraphsWidgetButtonsTest.php
   @@ -109,4 +109,32 @@ class ParagraphsWidgetButtonsTest extends ParagraphsTestBase {
   +    $this->drupalGet('node/add/paragraphed_test');
   

   You are not describing what the effective problem is - what specifically caused recusion. We should add comments that explain the problem.

Changed documentation for test functions and added more code comments to make code more understandable.

So, it sounds constructed, but the recursion could still indirectly happen if
A only allows B as child
And B only allows A child
;-)

We could only try to avoid that type of recursion by only allowing auto-population of each field once per host entity. Not sure what's the best definition.

A only allows B as child
And B only allows A child

Yes, my solution is not working for these cases. We still get recursion.

After discussion with @Berdir, if these situation happen that is because wrong configuration. We don't want to try to fix wrong configuration, we just won't to prevent crushing. After adding 5 level of nesting we stopped adding default paragraph type and display warning.
Without interdiff because approach are totally different.

I agree in general about "not fixing wrong config", but this behavior is the default behavior we propose if a paragraph type only supports itself as child type (until there is an opt-out). So it's likely not wrong custom config, but wrong default config. I'm not yet convinced to ignore that problem. ;-)

Yeah, i also thought once that a container paragraph type can be clearly differentiated from a content paragraph type.
But sometimes, Containers could have content too and work without a child. At least (custom) compositions that have extra content fields (plus support children). I still think we need more examples to understand these things right.

What if we - instead of trying to figure out if we are in a recursion from the paragraph types - we just try to figure out if we are in a recursion, by setting some flag when we assign a default value for the first time. Not sure how should we do exactly, but it might be worth investigating a bit.

I have re-rolled this patch against the 8.x-1.3 version

Hi! Maybe we should relate the issue https://www.drupal.org/project/paragraphs/issues/3022843 to the current one?

Since this is related to https://www.drupal.org/project/paragraphs/issues/3022843, which has been marked closed, works as designed, can this be closed as well?