FieldException: Attempted to create an instance of field with name field_* on entity type profile when the field storage does not exist.

Created on 2 December 2022, about 2 years ago
Updated 15 August 2024, 4 months ago

Problem/Motivation

A strange bug I've been looking into all day, and thought I should document here because I'm stumped as to root cause.

Symptom: a production site on Drupal 9.4.8 starts failing with "FieldException: Attempted to create an instance of field with name field_* on entity type profile when the field storage does not exist". When this happens, most pages are inaccessible.

This has happened four times in two weeks. The field names change but are valid field names; the entity type always appears to be "profile".

The stack traces seem to be any of the following:

in Drupal\field\Entity\FieldConfig::getFieldStorageDefinition called at /app/web/core/lib/Drupal/Core/Field/FieldConfigBase.php (331)
in Drupal\Core\Field\FieldConfigBase::isTranslatable called at /app/web/core/modules/views/views.views.inc (379)
in views_field_default_views_data called at /app/web/core/modules/views/views.views.inc (775)
in Drupal\field\Entity\FieldConfig::getFieldStorageDefinition called at /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php (1213)
in Drupal\Core\Entity\Sql\SqlContentEntityStorage::loadFromDedicatedTables called at /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php (502)
in Drupal\Core\Entity\Sql\SqlContentEntityStorage::mapFromStorageRecords called at /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php (427)
in Drupal\Core\Entity\Sql\SqlContentEntityStorage::getFromStorage called at /app/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php (393)
in Drupal\field\Entity\FieldConfig::getFieldStorageDefinition called at /app/web/core/lib/Drupal/Core/Field/FieldConfigBase.php (346)
in Drupal\Core\Field\FieldConfigBase::getSettings called at /app/web/core/lib/Drupal/Core/Field/FieldConfigBase.php (517)
in Drupal\Core\Field\FieldConfigBase::getItemDefinition called at /app/web/core/lib/Drupal/Core/TypedData/Plugin/DataType/ItemList.php (230)
in Drupal\Core\TypedData\Plugin\DataType\ItemList::getItemDefinition called at /app/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php (190)

The quick fix is to run drush cr which implies to me that somehow it is a cache corruption bug; field storage definitions are temporarily missing but then when caches are rebuilt the issue goes away.

We are using Redis as a cache backend and I wonder if that has anything to do with it; however the entity type so far has always been "profile" which is why I am raising it against this module.

Steps to reproduce

I have been trying for some hours and am unable to reproduce this on demand. I'm opening this here just to document that it happened and in the hope that someone has seen it before.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

💬 Support request
Status

Active

Version

1.0

Component

Code

Created by

🇬🇧United Kingdom longwave UK

Live updates comments and jobs are added and updated live.
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.

  • 🇧🇷Brazil veugenio

    I'm facing the same issue but when using the simplesamlphp library.

  • 🇨🇦Canada aarantes

    I'm facing the same issue...

    It started with Drupal 10 (maybe 10.1?). I'm now on Drupal 10.3.1 and the problem is still there...

    For me it is three different fields:

    - field user_picture on entity type user
    - field field_media_image on entity type media
    - field body on entity type block_content

    The strange thing is that these seem to be fields that exist (almost) by default. "body" and "user_picture" don't even have the traditional "field_" prefix...

    Moreover, something about this error causes the cache to get corrupted and I have to run "drush cr" (twice) to bring my site back online. The first "drush cr" gives me the same error of field exception. The second goes without problem and solves the issue.

    On top of that, my php-errors.log is littered with this error (some days it doesn't show, others it appears 300 or 400 times).

    I can go for days without having this issue and than it happens every day for a week, some days happening 2 or 3 times a day. And then, stop happening again for weeks, maybe months...

    I tried, following other articles to simply edit and save these fields without any changes (those articles were saying that this would solve any issues with missing/failed updates to the storage that might have been required by past upgrades.)

    I can't say if the re-saving of these fields have an impact (if after saving, the problem disappears for a while before reemerging...). What I can say is that it doesn't seem to change anything on the settings themselves (Configuration >> Development >> Synchronization shows no changes after these being re-saved).

Production build 0.71.5 2024