Contrib.social

Redirect response when executing migrate-rollback on console or mass deletion with views bulk operation

Open on Drupal.org →
Created on 9 March 2018, over 6 years ago
Updated 15 May 2024, about 1 month ago

Problem

When attempting to roll back a migration of Drupal 8 migrate, you get a HTTP redirect response:

$ drush migrate-rollback my_example

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="0;url=/public-node-url" />

        <title>Redirecting to /public-node-url</title>
    </head>
    <body>
        Redirecting to <a href="/public-node-url">/public-node-url</a>.
    </body>
</html>
Drush command terminated abnormally due to an unrecoverable error.          [error]

Migrate does not rollback the migration. There is no indication of an error or the cause anywhere to be found.

Cause

  1. Content Lock triggers HTTP redirect responses even when not in a webserver environment, but in a command line process.

  2. When attempting to run drush migrate-rollback or drupal migrate:rollback on the command line to roll back a migration, content_lock triggers a HTTP redirect response (still on the command line):

    $ drush migrate-reset-status my_example && drush migrate-rollback my_example --verbose --debug
...
...
Calling hook drush_migrate_tools_migrate_rollback [0.39 sec, 19.29 MB]               [debug]
Calling Drupal\migrate_tools\MigrateExecutable::rollback() [0.4 sec, 19.88 MB]               [debug]

#0  Symfony\Component\HttpFoundation\RedirectResponse->setTargetUrl() called at [/docroot/core/lib/Drupal/Component/HttpFoundation/SecuredRedirectResponse.php:58]
#1  Drupal\Component\HttpFoundation\SecuredRedirectResponse->setTargetUrl() called at [/vendor/symfony/http-foundation/RedirectResponse.php:39]
#2  Symfony\Component\HttpFoundation\RedirectResponse->__construct() called at [/docroot/modules/contrib/content_lock/content_lock.module:180]
#3  content_lock_entity_predelete()
...

Drush command terminated abnormally due to an unrecoverable error. [0.52 sec, 24.39 MB]         [error]

Proposed resolution

  1. Fundamentally, don't ever redirect on PHP_SAPI === 'cli', throw an appropriate exception instead.

  2. Ignore any content locks when a migration is rolled back, as this is not a random operation performed by an arbitrary other user in the system, but an administrative site maintenance operation.

Remaining tasks

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Needs work

Version

2.0

Component

Code

Created by

🇩🇪Germany sun Karlsruhe

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

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 →
    🇩🇪Germany osopolar 🇩🇪 GER 🌐

    Patch #22 also works for migration development where drush migrate:rollback {migration-name} failed with the message "Drush command terminated abnormally" due to redirect response.

  • Comment about 1 year ago →
    🇦🇺Australia sonnykt Melbourne, Australia

    Migrations can be rolled back via UI and I'm afraid that Content Lock still breaks migrations.

    IMO, a low-level CRUD hook is not an appropriate solution as it can break many operations using the entity_delete(), eg. bulk operations, cron, queue workers, etc.

  • First commit to issue fork.
  • Merge request !22Resolve #2951652 "Redirect response when" → (Open) created by smustgrave
  • Comment 3 months ago →
    🇺🇸United States smustgrave

    Opened MR for #22

  • Pipeline finished with Success
    3 months ago
    Total: 259s
    #125473
  • Status changed to Needs work 3 months ago
  • Comment 3 months ago →
    🇬🇧United Kingdom alexpott 🇪🇺🌍

    The way the redirect is done is wrong. What this issue should be doing is throwing an exception. It should then implement a listener that catches this exception and changes it into a redirect.

    The question then becomes what should something like migrate rollback do. Ideally whoever initiates a migrate rollback would break any necessary content locks before doing the rollback. For me this is the same with the views bulk delete. I think if the user has the "break content lock" permission then we should allow the delete to proceed. That would offer a few ways around this and everything would cleaner.

  • Comment 3 months ago →
    🇧🇪Belgium falc0

    Updated #22 to work with latest version.

  • Comment about 1 month ago →
    solideogloria

    @falc0, please apply the changes to the merge request. We should keep the MR up-to-date, rather than creating new patches.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024