Errors in field configuration can lead metatag_post_update_remove_robots_noydir_noodp() to fail

Thank you for providing details of the problem.

Do you have Drush installed, and would you mind running some commands?

drush php

Once that loads, paste this in:

\Drupal::entityTypeManager()->getStorage('field_storage_config')->loadByProperties(['type' => 'metatag']);

What does it say?

I am not the original poster, but am encountering this same exact issue with the update hook.

here is the output when running that command:

>>> \Drupal::entityTypeManager()->getStorage('field_storage_config')->loadByProperties(['type' => 'metatag']);
=> [
     "node.field_meta_tags" => Drupal\field\Entity\FieldStorageConfig {#9535
       +custom_storage: false,
     },
   ]
>>>

Ok, making this a blocker for the next release, and the 2.0.0 release.

Idea: please edit core/lib/Drupal/Core/Field/FieldConfigStorageBase.php and change mapFromStorageRecords() to this:

      try {
        if (!isset($record['field_type'])) {
          dump(['Failed record:' => $id]);
          dump($record);
          exit();
        }
        $class = $this->fieldTypeManager->getPluginClass($record['field_type']);

i.e. add the if() block above the $class definition. That way it should show you what field is failing.

  array:1 [
    "Failed record:" => ""
  ]
  array:1 [
    "required" => true
  ]

This is what is dumped when the update hook fails.

That suggests something is wrong with the field configuration - it shouldn't be failing that like.

Try this:

      try {
        if (!isset($record['field_type'])) {
          dump($records);
          exit();
        }
        $class = $this->fieldTypeManager->getPluginClass($record['field_type']);

That might hit an out-of-memory error. Try this:

      try {
        if (!isset($record['field_type'])) {
          dump(array_keys($records));
          exit();
        }
        $class = $this->fieldTypeManager->getPluginClass($record['field_type']);

It was indeed a misconfigured config entity.

In our case the site had custom update hooks to modify existing content entities. These hooks used the ConfigFactory->getEditable method to load them and change them. The getEditable method creates a new config entity if one with the name provided does not exist, so in those cases the update hooks had created config entities with just the keys they were modifying.

Please try updating with the latest 8.x-1.x codebase, I just committed a small rewrite of the post-update scripts that splits off the table logging into a separate function so we can more easily test it.

Once you do that, please try running the included _metatag_list_entity_field_tables() function on its own, see if that also fails.

DamienMcKenna: Still I ma getting the same issue.

Please try the steps I posted in #6 above, it might help identify the problem.

DamienMcKenna: I am getting the same output of #7. So i tried the #9 comment and i am getting the below output.

Oh! Interesting! It seems like there's a faulty config record somewhere.

@dk-massive: how did you identify the faulty config item on your site?

I wonder if we should wrap some of the lines in the foreach($fields as $field) loop in a try{} block, and then bail with a warning message if something comes up?

@DamienMcKenna: if any changes we can bypass the issue?

You'll want to fix the bug with your site, the logic that's showing you the configuration problem will multiple times with other Metatag updates.

@dk-massive: Could you please provide some sample code that creates the faulty config object so that I can test some options to work around it? Thank you.

@damienmckenna: sure thing
This to create a field that has nothing in it but a key you set. Adjust the 'page' to match a content type. In my case it was a paragraph type. I am not sure if it needs to be a field that existed before but was already deleted.

$config_factory = Drupal::service('config.factory');
$config_factory->getEditable('field.field.node.page.field_my_fake_field')->set('foobar', TRUE)->save();

You can use drush cget to check it in your terminal:
drush cget field.field.node.page.field_my_fake_field

You should see a config with nothing but that key you set.

This is what I used to clean it up on the sites I found:

$config_factory = Drupal::service('config.factory');
  $list = $config_factory->listAll('field.field');
  $fields = $config_factory->loadMultiple($list);

  foreach ($fields as $field) {
    if (!$field->get('field_type')) {
      $editable_config = $config_factory->getEditable($field->getName());
      $editable_config->delete();
    }
  }

I figure it is safe to remove any field configs without a field_type.

I hope this helps. Again my case was caused by paragraph fields, in case that is relevant.

Thank you, that'll help with building a workaround.

Ok, how about this? It basically catches the error and says to look at this issue on a discussion on how to fix the problem.

Patch #21 is for 2.0.x, this one is for 8.x-1.x.

Updated the issue summary with some sample code that can be used to find the faulty configurations.

It's possible to delete the configuration items using Drush too: $ drush config:delete [configname]

Committed. Thank you.

Automatically closed - issue fixed for 2 weeks with no activity.