Contrib.social

Implement form cache locking protection between the ApiLayoutController and the EntityFormController

Open on Drupal.org →
Created on 29 April 2025, 6 months ago

Overview

There is a race condition that can possibly triggered under the following conditions:

* User clicks 'add another item' in a multi-value widget in the page data form
* User enters a value in the new field (which received focus after 'add another item')
* User clicks 'add another item' which triggers a blur on the original field as well as an ajax request
* The former hits ApiLayoutController::patch with an update to the entity form fields
* The later hits EntityFormController and triggers a form state rebuild
* Both try to read and write from the same form build ID and may overwrite each other's changes
* the form build ID stored in autosave may no longer be the correct value if the the ajax command wins
* the form state stored in the form cache may no longer be accurate if the layout patch wins

Proposed resolution

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.
If we do this with Drupal's lock service in the backend, we might get into a place where we cannot reconcile the changes:
* 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.
* We can safely make the ajax request wait for the model patch because the form build ID is retained

User interface changes

📌 Task
Status

Active

Version

0.0

Component

Redux-integrated field widgets

Created by

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024