Prevent leftover fields from causing errors like "Call to a member function getLabel() after enabling layout_builder"

Created on 7 April 2020, over 4 years ago
Updated 13 April 2023, over 1 year ago

Problem/Motivation

If field definitions and field config and field storage config get out of sync (caused by failed migrations or direct editing of config), consumers of the Field API can unknowingly trigger logic errors.
For example, Layout Builder iterates over the field map provided by EntityFieldManager, and assumes that it contains an accurate listing.
If it does not (something which is not possible to achieve through the UI, only through deployment/developer interaction), the following error occurs:

Error: Call to a member function getLabel() on null in Drupal\layout_builder\Plugin\Derivative\FieldBlockDeriver->getDerivativeDefinitions()

Proposed resolution

Develop a mechanism to review broken fields in the UI
Prevent the Field API from exposing broken fields to consumers

Remaining tasks

User interface changes

An addition to /admin/reports/fields (or a subpage)

API changes

N/A

Data model changes

N/A

πŸ› Bug report
Status

Active

Version

10.1 ✨

Component
FieldΒ  β†’

Last updated about 16 hours ago

Created by

πŸ‡ΊπŸ‡ΈUnited States tim.plunkett Philadelphia

Live updates comments and jobs are added and updated live.
  • Blocks-Layouts

    Blocks and Layouts Initiative. See the #2811175 Add layouts to Drupal issue.

  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡©πŸ‡ͺGermany mkalkbrenner πŸ‡©πŸ‡ͺ

    We ran into this issue multiple times over the last two weeks, like @longwave in a running Drupal 9.5 during normal operations.
    One or more calls of drush cr solved the issue for some days.
    But it only happend on the production systems, never on a local development environment.

    I had a look at the code and see some problematic stuff.
    The key value store is database table. We use MariaDB replication. And we noticed a replication drift over the last weeks. Could it be that some action triggers the rebuild of the data but another process still reads the outdated data from a replicant which is some seconds behind the master. So this outdated data gets populated to the caches?
    In that case, key value store database queries should be changed to always query the database master.

    But the same could also happen if you use Redis or Memcache for fast chained caches.
    The new data could be written to the key value cache within a database transaction that also invalidates the cache. But for these non-Database caches, we don't have any transaction context. So another request could still read the old data from the key value store until the transaction gets committed and write old data into the cache.

Production build 0.71.5 2024