Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
If two people save the same configuration entity at the same time we don't use locking to ensure that one is saved and the other is rejected.
#2430219: Implement a key value store to optimise config entity lookups opens a new avenue for race conditions since saving two different configuration entities could result in missing information in the lookup key value storage.
Steps to reproduce the locking problem:
- Install Drupal standard
- Open the main menu admin (admin/structure/menu/manage/main)
- Add a second menu item
- Open the main menu admin in a second tab
- Change the menu items order and save
- Come back to your first tab
- Change the menu name and save
- You've lost the menu items order set in the second tab
Steps to reproduce the key_value storage problem:
These steps, suggested by @alexpott, are supposed to help someone whiling to write a test that demonstrate that problem.
- Create a test entity with a lookup key and a 'foo' base field
- In the test entity save method add a sleep if the 'foo' base field contains the 'bar' value
- In two different processes, save two different entities of this type, the first with foo=bar and the second with foo=notbar
- See what happens
Proposed resolution
TBD
Remaining tasks
Discuss, demonstrate, fix.
User interface changes
None.
API changes
Maybe.
Comments
Comment #1
DuaelFrComment #2
Dom. CreditAttribution: Dom. commentedCan you add reproduction step on this ?
Comment #3
DuaelFrComment #12
catchMoving this to a task - it'd be nice to have but it's not really a bug. Lots of configuration changes via form submissions on a live site is quite rare these days given config import/export. We have some basic concurrent editing protection for content entities, so could start by looking at whether any of that logic is transferable.
Comment #13
dwwTagging for bugsmash, since this started as a bug, and we triaged / discussed it in #bugsmash. Also moving the version.