Synced Patterns: Ensure recursion prevention is working correctly

[annezazu]

A report on X was brought to my attention where someone placed a reusable block (synced pattern) within itself causing a 500 error. This is reminiscent of a previously reported and handled problem described here #18704. As a result of that prior issue, a RecursionProvider component was created as well as simple conventions for preventing recursion on the front end. As noted previously, this was originally implemented in #28405, #28456, #31455. It seems there might be something off with the server warning based on the post on X so this is an issue to follow up to ensure things are working correctly. cc @mcsf who helped implement this work previously!

[talldan]

I did a quick test and it seems to work fine for the general use case.

In the block editor, there's a warning that a block cannot be placed within itself:

In the frontend, when you have debug mode on, an error message is shown there too (and without debug mode nothing renders for the affected block):

Not to say that it isn't impossible for a user. For example the site may have entirely replaced the code that renders patterns/reusable blocks (perhaps via a plugin), in which case they will have removed the code that protects against recursion.

There may also be other ways to exploit it, though I can't think of any, the PHP code is fairly simple and effective.

[mcsf]

Thanks for the issue and the debugging, @annezazu and @talldan!

Without detailed instructions to reproduce this bug, this will be difficult to fully diagnose. That said, in thinking about how runaway recursion can occur, it struck me that the thin wp:pattern wrapper isn't guarding against it:

gutenberg/packages/block-library/src/pattern/edit.js

Lines 77 to 81 in a7d76c3

	const clonedBlocks = selectedPattern.blocks.map( ( block ) =>
	cloneBlock(
	injectThemeAttributeInBlockTemplateContent( block )
	)
	);

gutenberg/packages/block-library/src/pattern/index.php

Lines 50 to 52 in a7d76c3

	$content = do_blocks( $content );

Now with the consolidation of terminology around "patterns" — synced or not synced — this has become easier to miss: synced patterns (formerly "reusable blocks") are protected, unsynced aren't.

I can confirm that one can create recursive dynamic patterns that crash both the front end and the editor, and I'll be sharing a fix soon. Due to the idiosyncratic mechanics of this block, the standard approach based on RecursionProvider will not work.

That said, the original report is odd in that only the front end crashes, but the editor correctly caught the recursion. I wonder if this could be the result of a strange mutual recursion, e.g. an unsynced pattern references a synced pattern which references the unsynced pattern back. This is pure conjecture, and perhaps a red herring.

[annezazu]

I'll do what I can to reach out to the original X poster and see if we can get more info :)

[mtias]

Nice debugging @mcsf