Widgets screen: sidebars endpoint returning inconsistent results for client/server

[talldan]

Describe the bug
When testing #25932, I noticed something curious about the sidebars endpoint.

I followed the steps for reproduction on #25932 and saw this:

Inspecting the data from the HTTP request, I noticed that none of the sidebars I'd created had a name property (unexpected), and they were all 'inactive' (probably expected since they were not assigned to an area).

Through coincidence I disabled preloading for this request by commenting out this line - https://github.com/WordPress/gutenberg/blob/master/lib/widgets-page.php#L88

This forces the browser to make the request, and when doing so the name property was then present for all of the sidebars and all of them also have status: "active". On the screen I see this:

[talldan]

I'm mostly concerned this might be a bug that we haven't noticed yet. Potentially though it might be a race condition, perhaps the preloading causes the data to be fetched much earlier before the plugin has had a chance to do some of its work.

[talldan]

This still seems to be an issue when the Custom Sidebars plugin is disabled as well, so probably unrelated to that plugin.

[gwwar]

@talldan I'm having a little trouble tracing where the preloading mechanism queries the DB. I think it may be easier to try and setup a unit test case for preloading to see if there's a race condition.

Edit: ah it's here https://developer.wordpress.org/reference/functions/rest_preload_api_request/

[noisysocks]

I tested this locally and can confirm that /v2/sidebars does not return sidebars registered using the Custom Sidebars plugin when the request is made by the server during preloading. It does return these sidebars when the request is made by the browser using JavaScript.

The issue is that the plugin has not had a chance to put the sidebar into the $wp_registered_sidebars global before the REST API request is made on the server by gutenberg_widgets_init.

We may be able to perform gutenberg_widgets_init later in the request lifecycle but I have not confirmed that yet.

[noisysocks]

Adding Needs Testing to this as I wonder if us calling retrieve_widgets() at the start of the endpoint has fixed this.

[anton-vlasenko]

I've tried to test this using the Gutenberg 12.4 RC1 plugin and WordPress 5.9 RC2.
If the Custom Sidebars plugin is enabled, /v2/sidebar always returns sidebars registered using the Custom Sidebars plugin (both during preloading or when using wp.apiFetch).
It doesn't depend on calling the retrieve_widgets function.
If the Custom Sidebars plugin is deactivated, /v2/sidebar never returns custom sidebars.
That makes sense to me.
I'd close this issue unless someone can reproduce the bug using the latest versions of WordPress and Gutenberg.