I ran a migration where I'd not yet mapped the bundle for the entity (because it was dynamic).

I accordingly got this result, as expected:

drush mi mymigration  --limit=1 --update
Missing bundle for entity type node                          [error]
(core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php:83)
Processed 1 item (0 created, 0 updated, 1 failed, 0 ignored) - done   [status]
with 'mymigration'

However, this left my migration map in a broken state: a map row was created with a source ID but no destination ID.

This means that subsequent migrations with --update crash, apparently because it tries to load an entity with a NULL id.

Comments

joachim created an issue. See original summary.

deepanker_bhalla’s picture

Hi,

It looked the same issue as mentioned below, thus kindly go through if it can help you out.

https://www.drupal.org/node/2678194

joachim’s picture

That's not quite the same issue.
I know where to put the bundle for the migration, which is the problem of the poster of that other issue.

This issue is about how Migrate should behave when that happens.

joachim’s picture

Version: 8.1.x-dev » 8.3.x-dev
Issue summary: View changes

This is handling a little better on 8.3 -- I still get a map row which I don't think should happen, but an --update migration doesn't crash, it merely produces the same 'Missing bundle for entity type' message.

joachim’s picture

Title: a failed migration row leaves a row in the map table, which then can't be updated » a failed migration row leaves a row in the map table
Priority: Major » Normal
mikeryan’s picture

Title: a failed migration row leaves a row in the map table » Migration in update mode does not properly handle previous errors

The existence of the map row is correct - the map table records all rows that are processed, with NULL destination IDs when there's an error or the row is explicitly ignored. You should be able to either rollback and reimport with a fixed migration, or as you are attempting use --update. Thus, the problem here isn't that the row exists in the map table, it's that running with --update after you've fixed the problem in the migration should result in a properly migrated entity and a map row with a normal status and destination ID.

joachim’s picture

> The existence of the map row is correct

On 8.1 this crashed, but on 8.3, doing an update just got me the same correctly reported error.

I've not tested 8.2. If the behaviour on 8.2 is the same as 8.3, then this can be closed as 'by design'.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mikeryan’s picture

Status: Active » Closed (works as designed)

On 8.1 this crashed, but on 8.3, doing an update just got me the same correctly reported error.

I've not tested 8.2. If the behaviour on 8.2 is the same as 8.3, then this can be closed as 'by design'.

With 8.3.0 coming out shortly, and as far as I can tell no further 8.2.x releases, there isn't going to be a backport of whatever the fix was to 8.2.x.