Log failed migration and provide an option to skip failed row from UI.

Ok I can see that the status of the migration in migrate map table seems to come from the core migrate module e.g.

interface MigrateIdMapInterface extends \Iterator, PluginInspectionInterface {

  /**
   * Indicates that the import of the row was successful.
   */
  const STATUS_IMPORTED = 0;

  /**
   * Indicates that the row needs to be updated.
   */
  const STATUS_NEEDS_UPDATE = 1;

  /**
   * Indicates that the import of the row was ignored.
   */
  const STATUS_IGNORED = 2;

  /**
   * Indicates that the import of the row failed.
   */
  const STATUS_FAILED = 3;

I am thinking it might be good to add another status e.g. STATUS_IGNORE

Also in the migrate_map* table we have level column. Possible options here are

  /**
   * Migration error.
   */
  const MESSAGE_ERROR = 1;

  /**
   * Migration warning.
   */
  const MESSAGE_WARNING = 2;

  /**
   * Migration notice.
   */
  const MESSAGE_NOTICE = 3;

  /**
   * Migration info.
   */
  const MESSAGE_INFORMATIONAL = 4;

On the migrate message table we have the following 'levels' that seem to pertain to message

  /**
   * Migration error.
   */
  const MESSAGE_ERROR = 1;

  /**
   * Migration warning.
   */
  const MESSAGE_WARNING = 2;

  /**
   * Migration notice.
   */
  const MESSAGE_NOTICE = 3;

  /**
   * Migration info.
   */
  const MESSAGE_INFORMATIONAL = 4;

I would expect a failed migration to be imported with MESSAGE_ERROR = 1 flag.

Thinking about this it seems a failed row with no destination id is omitted from the message table.

My guess is that migrate update will not attempt to import failed rows. Perhaps this makes sense to keep like this.

However a failed import will be logged in migrate_map table.

My guess is there is nothing to prevent this failing again on subsequent imports? (need to check how this works)

As migration message table has no record of rows with no destination id, It is not possible to manage this from the existing view, unless we add failed migrations (possible but possibly with ramifications when updating - need to check how this actually works).

So one option could be add another view that lists migration map status for all rows in the migration. This could simply add another status that could be modified from the UI to flag a row to ignore subsequent imports.

May also need to update code to skip any migrations with this status.

Some of this code is in core, while other is in contrib (migrate tools). This complicates slightly how this change could be made. My feeling is that it might make sense to add an additional status in core as that is where the other status constants are defined.

Maybe part of the issue I am experiencing may be related to m use of $this->logger->notice using MigrateException to handle exceptions. Will try switching from regular notice to see how this affects the migration.

I am thinking this makes more sense especially where entry exists in migrate map table.

This may also improve the reliability of the migration as well.