>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3521641. --> Reported by: [larowlan](https://www.drupal.org/user/395439) Related to !193 !238 >>> <h3 id="overview">Overview</h3> <p>There is a race condition that can possibly triggered under the following conditions:</p> <p>* User clicks 'add another item' in a multi-value widget in the page data form<br> * User enters a value in the new field (which received focus after 'add another item')<br> * User clicks 'add another item' which triggers a blur on the original field as well as an ajax request<br> * The former hits ApiLayoutController::patch with an update to the entity form fields<br> * The later hits EntityFormController and triggers a form state rebuild<br> * Both try to read and write from the same form build ID and may overwrite each other's changes<br> * the form build ID stored in autosave may no longer be the correct value if the the ajax command wins<br> * the form state stored in the form cache may no longer be accurate if the layout patch wins</p> <h3 id="proposed-resolution">Proposed resolution</h3> <p>Implement some form of locking, this most likely will need to be in the front end - we may need to pause ajax interactions in the page data form whilst the model is being patched.<br> If we do this with Drupal's lock service in the backend, we might get into a place where we cannot reconcile the changes:<br> * The form build ID sent in patchComponent will be out of date if the ajax request locks the form cache first. We would need to store something like a cache redirect in order for it to be able to continue.<br> * We can safely make the ajax request wait for the model patch because the form build ID is retained</p> <h3 id="ui-changes">User interface changes</h3> > Related issue: [Issue #3517868](https://www.drupal.org/node/3517868) > Related issue: [Issue #3536214](https://www.drupal.org/node/3536214) > Related issue: [Issue #3492065](https://www.drupal.org/node/3492065)