Maximum update depth exceeded error when calling replaceInnerBlocks

[gikaragia]

Description

The crash happens when replaceInnerBlocks is called with specific arguments. We encountered this bug while testing the plugin Sensei LMS with WP version 5.7. Unfortunately I wasn't able to be able to reproduce the bug outside of our plugin.

The loop seems to be introduced by the function useNestedSettingsUpdate and in the isShallowEqual check as the newSettings is an object containing the allowedBlocks array which is never equal causing infinite updates.

Interestingly the issue does not seem to happen when updateSelection is set to true.

I tried different Gutenberg versions and it seems that the bug was introduced in version 9.9.0 and it happens also in latest (10.2.1)

The issue where we originally discovered this is Automattic/sensei#4065 and we switched the argument of replaceInnerBlocks as a workaround in Automattic/sensei#4125

Step-by-step reproduction instructions

1. Install Sensei LMS plugin.
2. In this line update the updateSelection argument to false.
3. In admin go to Courses -> Add New
4. In the block with the title 'Course Outline' click 'Create a lesson'
5. Type a lesson name, add another lesson and update the post.
6. Remove the 'Course Outline' block and then readd it.
7. The call to replaceInnerBlocks happens after the lessons are retrieved from a custom endpoint and when we try to set the inner blocks of the 'Course Outline' block.

Expected behaviour

The block to not crash.

Actual behaviour

The block crashes.

WordPress information

• WordPress version: 5.7
• Gutenberg version: 9.9.0
• Are all plugins except Gutenberg deactivated? "No"
• Are you using a default theme (e.g. Twenty Twenty-One)? "Yes"

[talldan]

@gkaragia This sounds like a similar issue to #30274. Do any of your block edit components create a new array for allowedBlocks for every render? I think this could also happen with the template prop if any of your blocks do similar there.

[gikaragia]

Indeed @talldan we passed a new array for allowedBlocks in every render. Applying a similar fix with #30274 solved it. Thank you!

The underlying cause is going to be solved by #30311

[talldan]

Great, glad it was solvable. I'll close the issue.