Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
All the way back in #2664302: Semaphore table is only used by a core service but it depends on system install we made the semaphore table optional. This did not account, however, for the table not existing in DatabaseLockBackend::releaseAll().
Because that method only does anything if a request that acquired a lock is being terminated, the use-case for hitting this is rather esoteric for regular sites, as it requires the following to happen in that exact order:
- A request acquires a lock
- The response for that request is successfully sent
- The Drupal site is uninstalled
- The request is terminated, attempting to release the locks
In functional tests, however, this is less esoteric to hit, if the last request of the functional test happens to have acquired a lock.
Steps to reproduce
I have not been able to reproduce this locally, only on the Drupal.org CI. See https://git.drupalcode.org/project/config_overlay/-/jobs/6145015 for an example job in Config Overlay. The actual error was hidden quite well, so I had to patch core to expose it in the job output.
Proposed resolution
Check for the semaphore table not existing in DatabaseLockBackend::releaseAll() and do nothing if it does not.
Remaining tasks
User interface changes
-
Introduced terminology
-
API changes
-
Data model changes
-
Release notes snippet
-
Issue fork drupal-3540554
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
- 3540554-database-lock-release-all-no-table
changes, plain diff MR !12949
Comments
Comment #3
tstoecklerComment #4
tstoecklerPipeline is green and here is the test-only job, which correctly fails on the missing table exception: https://git.drupalcode.org/issue/drupal-3540554/-/jobs/6158126
Comment #5
smustgrave commentedSeems like a good defense approach that didn't break anything and does have coverage. No objections here.
Comment #6
mstrelan commentedLeft a question, not changing status for now.
Comment #10
catchAgreed on a follow-up to make the exception catching more specific but we could probably address that as part of #2371709: [PP-x] Move the on-demand-table creation into the database API, so maybe that issue is enough.
Committed/pushed to 11.x and cherry-picked back through to 10.5.x, thanks!