When purging a field definition, don't fail if field storage no longer exists

I ran into this same issue in the current 8.x versions of Drupal.
People might delete some of these tables by hand or using another method. If these tables are missing purging deleted tables will fail with an SQL exception. I would propose that we be more lenient and try to continue after a delete call to a missing deleted field table.

See also related issues https://www.drupal.org/node/2862308 , https://www.drupal.org/node/2836539 and https://www.drupal.org/node/2622160 .

Here's a patch that checks for missing field tables if the field is marked deleted and logs an error in the watchdog and continues afterwards.

Re-rolled the last patch for 9.3

I wonder if this is actually a bug.

This will need a test, adding tag. I though it would be easy to add a test to the existing one but I was not able to find an existing test for purging the field tables.

1. +++ b/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php
   @@ -1624,6 +1624,13 @@ protected function readFieldItemsToPurge(FieldDefinitionInterface $field_definit
   +    // If the field is deleted and the table has been removed from the db.
   ...
   +      // Warn and nothing more to do.
   

   This can be combined to one comment at the beginning of the if block. Maybe something like this,
   '//If the table does not exist just log a message.'

2. +++ b/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php
   @@ -1624,6 +1624,13 @@ protected function readFieldItemsToPurge(FieldDefinitionInterface $field_definit
   +      \Drupal::logger('entity')->error($this->t('The table @name was not found when reading field items to purge.', ['@name' => $table_name]));
   

   Is this an error or a warning?

It seems that it is also possible that the storage itself is missing and getFieldStorageDefinition throws a FieldException

So I added an extra try catch block there, as if there is no storage, then also nothing to do I guess.

for now the patch is for 9.5.

Adding a patch for drupal 10.1.x

This happened to me where the field storage was purged even though the deleted fields repository was tracking a field definition. I don't know the root cause. It may be due to cron running at the same time in the background and processing field_cron while the UI is also handling the field purge as well.

There is no lock used for this process to prevent duplicate purge runs on specific fields.

Edit: Example of adding a lock

  foreach ($fields as $field) {

    // Check if we can lock this field. If not, something else is purging this field.
    $lock_id = "field_purge:{$field->getUniqueIdentifier()}";
    if (!\Drupal::lock()->acquire($lock_id)) {
      continue;
    }
    $entity_type = $field->getTargetEntityTypeId();

    $count_purged = \Drupal::entityTypeManager()->getStorage($entity_type)->purgeFieldData($field, $batch_size);
    if ($count_purged < $batch_size || $count_purged == 0) {
      // No field data remains for the field, so we can remove it.
      field_purge_field($field);
    }

     // Release the lock.
    \Drupal::lock()->release($lock_id);

    $batch_size -= $count_purged;
    // Only delete up to the maximum number of records.
    if ($batch_size == 0) {
      break;
    }
  }