Contrib.social

Stub entity conversion to real entities easily slip into error on changed field presave

Open on Drupal.org →
Created on 8 August 2017, almost 7 years ago
Updated 12 June 2024, 16 days ago

Problem/Motivation

Note: I am filing this against Drupal 8.2, but have not seen any issues or changes which clarified to my mind that this was fixed.

A difficult to troubleshoot error on migrations related to the update of a stubbed entity to the "real" entity. Here is an example of the error:

Error: Call to a member function hasTranslation() on null in Drupal\Core\Field\Plugin\Field\FieldType\ChangedItem->preSave() (line 47 of           [error] /var/www/build/html/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/ChangedItem.php) #0

As context, I have raised this issue in both #2543726-75: Make $term->parent behave like any other entity reference field, to fix REST and Migrate support and de-customize its Views integration → and #2841311-19: Initialized fields of an entity clone have a reference to the original entity object instead to the cloned entity object → to address an earlier instance of this error, but a change in the content on the site resurfaced it in another way. It seems very easy to fall into this error based on a variety of mismatch issues of entity ID, entity bundle, and so on.

For a detailed sequence of how I'm currently reproducing this:

  • Drupal 8 to Drupal 8 migration.
  • The migration uses the remote UUID as the source ID AND the migration maps the serial ID (tid, etc)
  • Stubs are created using the next available serial ID. This serial ID is then included in the migrate map for destid.
  • When the "real" entity is to be migrated, its UUID is used to look up the destid in the migrate map, and it finds the stub ID.
  • The migration process then builds an entity to update, building a data structure where it is attempting to change the serial ID.
  • On preSave, the system attempts to load the original entity, however, because the serial ID changed from a generated term to the source term, the original object will be set to the wrong entity or to NULL if it fails to find an entity for the designated source ID.
  • ChangedItem field plugin is the first spot that assumes original will be populated, but if you hard-code a simple check the next spot down the line will explode in a similar manner.

Proposed resolution

Site Migration Developer Workaround

If the migration is using the entity id key in a process destination mapping, make sure the stub row in the MigrationLookup plugin explicitly sets the value from target_id as the stub entity ID. This can be done in newer versions of Drupal by subclassing the MigrationLookup plugin to more explicitly manage the contents of the stub row. #2835586: Allow customization of stub rows from Migration process plugin →

Core Options

  1. If a process plugin is mapping the entity id but a different field is designated for sourceid, the MigrationLookup (when supporting stubs) should raise an exception.
  2. Core should have a more explicit check/exception about changing serial IDs if it's going to explode this way, perhaps in preSave
  3. Enable Migration destination entity validation by default (in case such validation would catch this, which seems likely) #2745797: Add option to content entity destinations for validation →

Remaining tasks

Determine the appropriate solution.

User interface changes

N/A

API changes

TBD

Data model changes

TBD

🐛 Bug report
Status

Closed: cannot reproduce

Version

11.0 🔥

Component
Migration  →

Last updated 1 day ago

Created by

🇺🇸United States Grayside

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.

  • Comment about 1 year ago →
    🇦🇺Australia acbramley

    For me, this needs a bit more straightforward steps to reproduce. Maybe a sample migration? Does the issue still exist on 10.1.x?

    Removing needs tests cause theres no code to test yet.

  • Status changed to Closed: cannot reproduce 16 days ago
  • Comment 16 days ago →
    🇦🇺Australia acbramley

    As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)". This issue was marked "Postponed (maintainer needs more info)" over a year ago.

    Since there aren't steps to reproduce the issue provided since the issue was postponed, I'm marking the issue "Closed (cannot reproduce)". If anyone can provide complete steps to reproduce the issue (starting from "Install Drupal core"), document those steps in the issue summary and set the issue status back to "Active".

    Thanks!

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024