Clicking save in Gutenberg editor causes multiple admin-ajax.php calls

[Ciantic]

Describe the bug When clicking save in Gutenberg it triggers multiple POST requests

How to reproduce the bug Steps to reproduce the behavior:

1. Go to WordPress page editor
2. Open developer tools
3. Click on save button
4. See network tab and admin-ajax.php calls

On my machine it triggers multiple POST requests to the admin-ajax.php with this kind of payload:

On my test (4-10 extra POST requests)

{
    "success": true,
    "data": {
        "data": {
            "seobar": "
....",
            "metadescription": "",
            "ogdescription": "",
            "twdescription": "",
            "imageurl": ""
        },
        "processed": [
            "seobar",
            "metadescription",
            "ogdescription",
            "twdescription",
            "imageurl"
        ]
    }
}


Expected behavior
Only one request to save the details
Additional context
Google Chrome and latest WordPress.
I've yet to test with other sites.

[sybrew]

Thank you for the detailed bug report!

The admin-ajax.php calls are for a feature where TSF fetches updated metadata, a new SEO Bar, etc., after saving.

Gutenberg doesn't handle its saving subscription well. Hence, there are multiple calls for it in rapid succession.

We have already debounced most of the duplicate calls. This debouncing filters out duplicated calls by delaying our callbacks for 0.5 seconds. If 0.5 seconds haven't passed, and another save action occurs, we wait for another 0.5 seconds. Once this 0.5 is passed, TSF performs its on-save actions, such as making the admin-ajax.php calls.

If the browser or server responds too slowly and the saving calls are more than 0.5 seconds apart, TSF will indeed repeat its saving sequence.

I won't increase the debouncing delay of 0.5 seconds because the lag with the user interface would become too significant. We also cannot accurately determine whether a user saved twice in succession or that Gutenberg is still unworkable.

This must be fixed upstream. Gutenberg's team already tried to address this a couple of times in the past, but I'm sure there's more work to be done:

1. https://github.com/WordPress/gutenberg/issues/14759
2. https://github.com/WordPress/gutenberg/pull/17522

Still, please let me know if you find that the admin-ajax.php calls repeat in under 0.5 seconds (500 milliseconds) because that would be a bug in The SEO Framework.

With that, I recently reworked TSF's debouncers to be native JS, which will ship with the next update. The change also affects this part of the saving sequence, although I do not think you'll find an improvement in this situation. But it did get me up to speed with this issue.

[drzraf]

We had a customization (implying some wp.data.dispatch('core/editor').lockPostSaving('metalock') in some editing cases)

But in this situation, the old debounce function (the 5.0.x buggy implementation, with no reference to timeoutId) triggered an infinite loop enqueuing thousands of XHR during 500ms available, all of them being later sent, as soon as locking was removed.

Such a flood of thousands of XHR is likely to overwhelm any server backend (as it did for us multiple times until we pinpointed this root cause)

Seems fixed in 5.1.x

[sybrew]

Thank you, @drzraf, for providing feedback on this issue.

It appears that in September (when I left the comment above), I forgot that I made a change in May that wasn't shipped yet at the time of writing, and I went off on a tangent that wasn't causing the issue in the first place. Sorry about that.

Then, this issue appears to be fixed thanks to https://github.com/sybrew/the-seo-framework/commit/86910019ffa9e28679e542fa284400da47be3742.

Later, I ported that functionality from Gutenberg only to the new public tsfUtils.debounce() method.

I'll retroactively add this issue to the 5.1.0 milestone and mark it as completed.

Please let me know if you are still encountering this issue, @Ciantic. Cheers!