Functional tests attempting to release locks for a no-longer existing site throws an exception

Created on 9 August 2025, 3 days ago

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:

  1. A request acquires a lock
  2. The response for that request is successfully sent
  3. The Drupal site is uninstalled
  4. 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

-

🐛 Bug report
Status

Active

Version

11.0 🔥

Component

lock system

Created by

🇩🇪Germany tstoeckler Essen, Germany

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

Comments & Activities

Production build 0.71.5 2024