Add a continue on failure option

Created on 21 January 2022, almost 3 years ago
Updated 27 April 2023, over 1 year ago

Problem/Motivation

Sometimes a migration fails because a source site is down, causing a failure, which puts the migration status into the importing state forever until the migration is reset. This can be confusing for some users, because it is an idiosyncrasy with migrate that takes time to understand.

A possible solution for avoiding this status stasis, could be to run the migration with the --continue-on-failure flag set.

Proposed resolution

Add a checkbox to add the continue on failure flag.
Add the flag to https://git.drupalcode.org/project/migrate_queue_importer/-/blob/8.x-1.x...

User interface changes

Add a checkbox to add the continue on failure flag.
https://git.drupalcode.org/project/migrate_queue_importer/-/blob/8.x-1.x...

Data model changes

add the continue on failure option to schema https://git.drupalcode.org/project/migrate_queue_importer/-/blob/8.x-1.x...

✨ Feature request
Status

Needs work

Version

2.0

Component

User interface

Created by

πŸ‡ΊπŸ‡ΈUnited States trackleft2 Tucson, AZ πŸ‡ΊπŸ‡Έ

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.

  • πŸ‡ΊπŸ‡ΈUnited States trackleft2 Tucson, AZ πŸ‡ΊπŸ‡Έ

    Oh, sorry I missed this, I'll check it out.

  • πŸ‡¬πŸ‡§United Kingdom 2dareis2do

    if running multiple migrations, when one migration reports any failure, the entire process stops with that migration and subsequent migrations are not run. That's not necessarily desirable, especially when developing a set of migrations where you'd like it to run the whole thing and gather all the errors from all the migrations rather than have to identify and fix them one at a time. So, I propose a --continue-on-failure option to the migrate-import command, which will run all selected migrations whether or not one in the middle fails.

    https://www.drupal.org/project/migrate_tools/issues/3092369 β†’

    I am a bit confused by this feature request, The example shown seems to apply for groups. i.e. if one item in the group fails, then the next one is not skipped.

    How does this apply to migrate queue importer that does not support groups AFAICT?

  • πŸ‡ΊπŸ‡ΈUnited States trackleft2 Tucson, AZ πŸ‡ΊπŸ‡Έ
  • πŸ‡¬πŸ‡§United Kingdom 2dareis2do

    In my experience there are some issues when running dependencies using migrate tools UI or via drush/cron. From what I can tell the options are ignored for dependencies. e.g. if I specify to limit say 1 row, this appears to be ignored when running the dependencies as part of the main migration.

    I think it might be better to run a migration dependencies separately i.e. select the option to ignore dependencies and run each one separately. This should make sure a dependency runs even if there is an error with a row in the parent migration.

  • πŸ‡ΊπŸ‡ΈUnited States trackleft2 Tucson, AZ πŸ‡ΊπŸ‡Έ

    You need the entire dependent migration to run if it exists. The row limit should only apply to the main migration you're controlling. The dependent migrations shouldn't be limited because their successful completion is crucial for ensuring the main migration can run properly.
    Limiting dependencies could lead to incomplete data or other issues downstream.

  • πŸ‡¬πŸ‡§United Kingdom 2dareis2do

    Often you just want to update a single row for a migration and its dependencies. When specifying a limit, this ignored by dependencies. In fact, I cannot think of a single case where I want to limit the main migration but not one of its dependencies.

    e.g. if I use one or more migration_lookup in my main migration, i should be able to specify an id and it will just import that one. However, even if i limit it by one, the dependencies will run in their entirety. This can be very tine consuming, and in my case unnecessary.

  • πŸ‡¬πŸ‡§United Kingdom 2dareis2do

    Actually --continue-on-fallurre does seem to do something. I am getting the following output if I do not specify it.

    [notice] Processed 4 items (0 created, 0 updated, 4 failed, 0 ignored) - done with 'my_import_feed'
    
    In MigrateToolsCommands.php line 1092:

    The code for this is like so:

    if ($error_message) {
          if ($options['continue-on-failure']) {
            $this->logger()->error($error_message);
          }
          else {
            // Nudge Drush to use a non-zero exit code.
            throw new \Exception($error_message);
          }
        }
    

    If I understand this correctly this is useful to prevent drush outputting a non zero value

    By convention, an exit code of zero indicates that the command completed successfully, and non-zero means that an error was encountered.

    https://linuxize.com/post/bash-exit/

Production build 0.71.5 2024