EntityStorageException after field delete and reimport

Discussed with @xjm and @catch. We agreed that this is a major bug. However, I think there is a simple work around - just run cron until the first field is purged.

Keep running into this with migrate, running cron as a work around

I think there's another way to produce this as well, which is probably a lot more likely to crop up in standard configuration management workflows.

1. Create a field via a module's default config, so it has a random UUID (probably creating via the UI would work the same)
2. Try to import a stored configuration of that field that has a different UUID.

This is exactly what would happen if you installed a site and then imported configuration from config/default, which is a standard configuration management workflow.

Similarly, you can recreate this by simply changing the UUID on a field storage configuration and trying to re-import it (as would happen if you had deleted and recreated it via the UI).

The only current workaround is to run the configuration import twice via Drush (which doesn't seem to fail on this exception like the UI does). The field will be deleted the first time, and recreated the second time.

I haven't been able to reproduce with the step-by-step from the IS.

Env: fresh new Drupal 8.4.x and Drush 9.0.0-beta1

• Run drush @site.env cex -y
• Visit /admin/structure/types/manage/article/fields/node.article.field_image/delete and hit Delete
• Confirm the Tags field is missing
• Import the saved configuration:

$ drush @site.env cim -y
 Colle  Config                                         Operation                
 ction                                                                          
        field.storage.node.field_image                 create 
        field.field.node.article.field_image           create 
        core.entity_form_display.node.article.default  update 
        core.entity_view_display.node.article.teaser   update 
        core.entity_view_display.node.article.rss      update 
        core.entity_view_display.node.article.default  update

 // Import the listed configuration changes?: yes.                                                                      

 [notice] Synchronized configuration: create field.storage.node.field_image.
 [notice] Synchronized configuration: create field.field.node.article.field_image.
 [notice] Synchronized configuration: update core.entity_form_display.node.article.default.
 [notice] Synchronized configuration: update core.entity_view_display.node.article.teaser.
 [notice] Synchronized configuration: update core.entity_view_display.node.article.rss.
 [notice] Synchronized configuration: update core.entity_view_display.node.article.default.
 [notice] Finalizing configuration synchronization.
 [success] The configuration was imported successfully. 

• Visit admin/structure/types/manage/article/fields and confirm the Tags field is back.
• Now go back to admin/structure/types/manage/article/fields/node.article.field_tags/delete and hit Delete again
• Observe the field is gone and there's no error showing up in the UI
• Repeat

Now, to rule out Drush I performed the same exact steps, but by exporting/importing the config through the UI instead of using Drush. Same results.

As to:

Similarly, you can recreate this by simply changing the UUID on a field storage configuration and trying to re-import it (as would happen if you had deleted and recreated it via the UI).

I tried to create a 'Test' field, export the config, then change its UUID in field.storage.node.field_test and import again. This gave me:

$ drush @site.env cim -y
 Collection  Config                         Operation                
             field.storage.node.field_test  create 
             field.storage.node.field_test  delete

 // Import the listed configuration changes?: yes.                                                                      

 [notice] Synchronized configuration: delete field.storage.node.field_test.
 [notice] Synchronized configuration: create field.storage.node.field_test.
 [notice] Finalizing configuration synchronization.
 [success] The configuration was imported successfully.

Then I tried to repeat the step-by-step from #9 with that new test field and it worked perfectly. Via the UI, I tried to single export/import (by changing the UUID) and got the expected "An entity with this machine name already exists but the UUID does not match.".

If I delete the test field and try to single import that particular field storage config (with a modified UUID) it then works immediately, (even if the field won't appear in the UI because it'll miss other files). If I drush @site.env cim -y again it'll work just fine, by deleting and recreating the field storage file. My test field will show up again as expected in the UI.

We really need an IS update because at this point either the bug no longer exists with 8.4.x or we need to clarify even further the steps to reproduce.

Thanks a lot @anavarre. I also just attempted and failed to reproduce all of these issues (IS, plus my two scenarios in #8) on a fresh Lightning install (Drupal core 8.3.1).

I think this is more nuanced than appears at first glance, and probably confounded by other issues as well.

My best guess is that the original issue here was solved in Drupal 8.1, 8.2, or 8.3.

The subsequent reports by me and Joel might be due to other issues, such as this Lightning bug. Basically, if a module tampers with configuration while a sync is in progress, all sorts of unanticipated things could happen. This explains some of the problems I saw, and could explain Joel's report about Migrate.

I don't think this explains everything though. We definitely hit this bug recently doing a simple configuration import. I'll see if I can come up with steps to reproduce.

I've run into this error with a site that was having trouble deleting some config. Somehow this caused drush entity-updates to trigger "The media.field_description field needs to be uninstalled." for a few different fields. I don't know how this came about since entity-updates doesn't usually happen on field api fields...

drush entup
cause this error

[error] Drupal\Core\Entity\EntityStorageException: Exception thrown while performing a schema update. SQLSTATE[42S02]: Base table or view not found: 1146 Table '1_stock25.socks25node_revision__field_sayt' doesn't exist: SELECT 1 AS expression
FROM
{node_revision__field_sayt} t
WHERE field_sayt_target_id IS NOT NULL
LIMIT 1 OFFSET 0; Array
(
)
in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1481 of /var/www/virtual/stock25.com.ua/htdocs/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Array Array
[success] Cache rebuild complete.
[success] Finished performing updates.

@sslam I'm moving the version back to 8.6.x-dev because that is likely the branch we will make the fix on.

I got the same error under different circumstances.

Using code to load new configs to overwrite entity form and form display to remove a field programmatically and later if I try to delete the storage via code I got the same issue reported in this issue.

$field_media_license_storage = FieldStorageConfig::loadByName('media', 'field_media_license');
  if($field_media_license_storage) {
    $field_media_license_storage->delete();
  } 

Exception thrown while performing a schema update. Cannot rename media__field_media_license to field_deleted_data_0ef9fd8218: table field_deleted_data_0ef9fd8218 already exists.

Is there a way to manually fix this while the actual fix is being worked on? Running cron and entity updates does not fix it.
[Edit]: I reverted the database and re-ran cron + entity updates a couple of times and it worked this time.

I am hitting this error. I deleted a field in the UI and then recreated it, with the same machine name, but as a different field type. After a config export, the YML file has a new UUID and field_type. Then running config import against the original database throws this error. As suggested in #8, running config import a second time works as expected.

In ConfigImportCommands.php line 261:
                                                                                                                                                                        
  The import failed due to the following reasons:                                                                                                                       
  Unexpected error during import with operation delete for field.storage.node.field_masthead_image_desktop: Exception thrown while performing a schema update. Cannot   
  rename node__field_masthead_image_desktop to field_deleted_data_f18c52ec79: table field_deleted_data_f18c52ec79 already exists.

Drupal\entity_reference_integrity_enforce\Exception\ProtectedEntityException: Cannot delete "media" because other content is referencing it and the integrity of this entity type is enforced. in Drupal\entity_reference_integrity_enforce\EntityPredelete->entityDelete()

Getting issue like this while deleting any media file.

Please help me out to solve the problem.

@EdgarPE, thanks for creating this issue.

I tested this on 9.5.x and was not able to reproduce this error. I followed the steps given in the Issue Summary.

Therefore, closing as outdated.

If you are experiencing this problem on a supported version of Drupal reopen the issue, by setting the status to 'Active', and provide complete steps to reproduce the issue (starting from "Install Drupal core").

Thanks!

I hit this error in my development process working on a dev copy of a site.
It can be reproduced as follows:

1. Remove a field from your database (Drupal will rename the database table).
2. Export configuration.
3. Load a database snapshot from production (for example to debug a separate issue).
4. Import configuration.
5. Error occurs. In my case: Unexpected error during import with operation delete for field.storage.node.field_need_date_change: Exception thrown while performing a schema update. Cannot rename 'node__field_need_date_change' to 'field_deleted_data_f21a3876bc';: table 'field_deleted_data_f21a3876bc'; already exists.

The cause in my case was that I did not drop my existing database when loading the snapshot, I just simply loaded a mysqldump. This overwrites existing tables, but does not delete tables from your database which are not present in the new snapshot. So the previous copy of field_deleted_data_f21a3876bc from step 1 was still there in my local database, remained when loading the snapshot, and caused the error when I tried to import my configuration.

The workaround is to do drop database, create database before loading your snapshot, to clear out any unwanted tables like this.

This error occurs on several of our sites when we try to remove the date_recur field. I have tried it on simplytest.me with version 3.3.0 on
a clean Drupal 10.4.1 and the same error occurs. I updated my local site to use version 3.8.1 and have the same error.

I created a clean Drupal 10.4.1 install locally, and installed 3.8.1 and am getting the error.

My fault, this issue was not the one I meant to add this comment to. It's a date recur issue.