> [!note] Migrated issue > > <!--Drupal.org comment--> > > <!--Migrated from issue #3520592.--> > > Reported by: [tedbow](https://www.drupal.org/user/240860) > > Related to !931 ### Updated description (2027-07-21): I, @f.mazeikis , was [validating the steps to test](https://git.drupalcode.org/project/canvas/-/work_items/3520592#note_890518) and came to a different conclusion than the original description was describing. ### Overview I am uncertain if this is two issue or one. Original description, debugging and steps to test puts emphasis "speed of user actions" and on this: > The 409 error happens because the request to `ApiAutoSaveController::post()` could not possibly have the latest auto-save hashes because there has not been a new request to `ApiAutoSaveController::get()` In my attempts to replicate the issue, it doesn't seems that the `HTTP 409` and the UI error occurs due to "race condition, where user publishes their changes before the latest hash is available after making a change to auto-save item", but instead is far more simple: When a user selects their changes for publishing in "Unpublished changes" panel, their changes at that time are "staged" and any further changes to the already selected item do not update what has been "staged" on inital item selection. This results in auto-save item on BE being updated (getting new hash), but changes "staged" in UI not being updated with the latest hash, unless the user re-selects their changes. This results in the HTTP 409 error. With that being said, @tedbow investigation into a race might still be valid and there is a separate issue, where "a POST call in-progress to update auto-save item has not received response before a POST call to publish the same auto-save item was made, resulting in publishing request containing already stale auto-save hash". This certainly sounds plausible, but depending on how the "stale stagged changes" issue is solved in UI, it might only be theoretical. For example, if all auto-save items are unselected on closing "Unpublished changes" panel or any change to selected auto-save item immediately unselects it (before a HTTP call to update the auto-save item is even made). ### **Steps to reproduce:** 1. Make any change to a published Page entity in Canvas UI 2. Click 'Review 1 change' button in top right corner, wait for "Unpublished changes" panel to appear. 3. Select the changed Page entity for publishing, but do not publish. 4. Close the "Unpublished changes" panel without unselecting the Page entity (method of closing the panel is irrelevant). 5. Make additional change to the same Page entity. 6. Click 'Review 1 change' button in top right corner again, wait for "Unpublished changes" panel to appear. 7. The Page entity should still be selected - do not re-select it, just click "Publish 1 selected" button. 8. Observe: * `HTTP 409` response from `HTTP POST` call to the `/canvas/api/v0/auto-saves/publish` endpoint * UI error message in "Unpublished changes" panel "_An item in the publish request did not match the expected format or value. Please refresh your page and try again._" * UI error prompting user to refresh their page * Further attempts to publish entity fail with the same error (regardless if any further changes were made or the changes in step 5 were unmade) * Unselecting and re-selecting item in "Unpublished changes" panel allows successful publishing, but saved entity now is in the state at the time of publishing in step 7. 9. Refreshing the Page as prompted, selecting the changes again and publishing works as expected. Any changes to entity after the error observation in step 8 are lost, resetting entity to the same state as at the start of step 7. ### Proposed resolution: I see a few ways to solve this, with first seeming to be the easiest: 1. We could "unselect all items when 'Unpublished changes' panel is closed or loses focus". Currently, when a user selects their changes and refreshed the page, all items are unselected, so we do have precedent for unselecting changes already. 2. The auto-save item that has been changed since being selected could be unselected. 3. The auto-save item that has been changed since being selected could be "refreshed", making sure the latest version of auto-save item is "staged" for publishing. 4. The entire list of items selected for publishing could be refreshed if any of selected item are updated Just in case the previous discussion is still valid and there is a separate race condition, I'm leaving original debugging and findings as is: --- ## Original description: ## Overview found this from [<span dir="">#3520067: \[Needs design\] Confusing messages when publishing immediately after making changes: auto-save race condition</span>](https://www.drupal.org/project/experience_builder/issues/3520067 "Status: Closed (fixed)")\ @lauriii wrote > I ran into this by making a change and then quickly trying to publish it after making that change. I think the error I got was "This item is unexpected." and it was really confusing because I had no idea what is "this" in the context of the message and why it was unexpected. I was able to reproduce this too but not consistently **Steps to reproduce:** 1. Add a heading component to the canvas. 2. Change the styling from **Primary** to **Secondary** and wait until the 'Review 1 change' button appears. 3. Click inside the text field to edit it (while keeping your cursor near the 'Review 1 change' button), then quickly enter some text, click the review button, and immediately publish. 4. You will encounter a **409 (Conflict)** error with the message: \ \ _"An item in the publish request did not match the expected format or value. Please refresh your page and try again."_  **Details seen in the network response:** <pre>{ "detail": "An item in the publish request did not match the expected format or value. Please refresh your page and try again.", "source": { "pointer": "xb_page:1:en" }, "code": 2, "meta": { "entity_type": "xb_page", "entity_id": "1", "label": "Test page", "api_auto_save_key": "xb_page:1:en" } } </pre>What is probably happening with "then quickly enter some text, click the review button, and immediately publish." from above: 1. Entering the test will trigger a POST request to `\Drupal\experience_builder\Controller\ApiLayoutController::post` 2. This triggers a request will result in the AutoSave entry for the entity to be updated 3. There is request to `\Drupal\experience_builder\Controller\ApiAutoSaveController::post()` which receives a 409 4. **After** that there is request to `\Drupal\experience_builder\Controller\ApiAutoSaveController::get()` I am not sure what triggers the last request to `ApiAutoSaveController::get()`. My guess would be that it is **NOT** clicking "review x changes" or that would happen **before** the request to `ApiAutoSaveController::post()` which is triggered by clicking "Publish all changes" The 409 error happens because the request to `ApiAutoSaveController::post()` could not possibly have the latest auto-save hashes because there has not been a new request to `ApiAutoSaveController::get()` ### Proposed resolution #### Original suggestion When returning the updated layout preview also return the item's auto-save Merge this on the client side with the existing list of auto-saves #### Updated suggestion I, tedbow, made the original suggestion. I realize now without front-end changes this likely would solve the problem. If there nothing stops the user from clicking "Publish all changes" before the request to `\Drupal\experience_builder\Controller\ApiLayoutController::post` returns it won't matter if we update the auto-save entry on the client side when the `ApiLayoutController::post` request returns because the POST request to `ApiAutoSaveController::post()` would have already been sent with the old aut-save hash. The safest method I think would be 1. When the user clicks "Review X Changes 2. disallow any new UI changes. 3. Disable the "publish all changes" button 4. If there are any existing requests to update the layout then wait for them to return 5. Make a request to `ApiAutoSaveController::get()` to update the publish list 6. only then after the client data has been updated then enable the "publish all changes" button which would the request to `ApiLayoutController::post` ### User interface changes > Related issue: [Issue #3522368](https://www.drupal.org/node/3522368) > Related issue: [Issue #3526907](https://www.drupal.org/node/3526907)