Contrib.social

Improve error reporting from migrate_drupal_migration_plugins_alter()

Open on Drupal.org →
Created on 13 February 2021, almost 4 years ago
Updated 30 January 2023, almost 2 years ago

Problem/Motivation

When Drupal cannot connect to the migration database, migrate_drupal_migration_plugins_alter() adds an error to the messenger service:

Failed to connect to your database server. The server reports the following message: No database connection configured for source plugin variable.

  • Is the database server running?
  • Does the database exist, and have you entered the correct database name?
  • Have you entered the correct username and password?
  • Have you entered the correct database hostname?

There are two problems:

  1. The problem usually has nothing to do with the variable source plugin.
  2. Adding the error to the messenger service means that it is unpredictable where this error will be displayed.

The same error message is generated by the credential form in migrate_drupal_ui. The first problem applies there, but not the second.

Steps to reproduce

WIth Drush:

  1. Install Drupal with the Standard profile.
  2. Enable the migrate_drupal module.
  3. Clear caches: drush cr.
  4. Check migration status: drush ms. You will see the error message.

WIth 📌 Add ability to view migrate_message table data Fixed :

  1. Install Drupal with the Standard profile.
  2. Enable the migrate_drupal module.
  3. Add test_log.yml → to the migrations/ directory of any enabled module.
  4. Execute the test_log migration. It should create one migration message.
  5. Clear caches and visit /admin/reports/migration-messages. You should see the error message.

Proposed resolution

For (1), move the error message reported by the server after the list of suggested remedies.

For (2), find a more reliable way to track errors.

Remaining tasks

User interface changes

Different error messages.

API changes

None

Data model changes

None

Release notes snippet

N/A

📌 Task
Status

Needs work

Version

10.1 ✨

Component
Migration  →

Last updated 4 days ago

Created by

🇺🇸United States benjifisher Boston area

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

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 almost 2 years ago →
    🇺🇸United States danflanagan8 St. Louis, US

    It looks like the latest patch makes both of the changes on the "Proposed Resolution". But per @mikelutz in #9 this still needs tests. Tagging and setting back to NW.

  • Comment almost 2 years ago →
    🇺🇸United States benjifisher Boston area

    Part of the difficulty with this issue is that we do not have good steps to reproduce the problem. We need that before we can write a test.

    It is easy with Drush: just enable the migrate_drupal module and drush cr and drush ms. But we need a way to reproduce the problem with just Drupal core.

    I previously suggested (in the issue description) using the patch from 📌 Add ability to view migrate_message table data Fixed . In order for that to work, you need to run some migration that creates messages. You could do a full migration from D6 or D7. A more minimal approach is to add the attached migration to mymodule/migrations/, where mymodule is any enabled module. Then execute the migration: it will add one message. I am updating the issue summary to suggest this.

    Unless someone can think of a better way to test, we may as well postpone this issue on #3063856.

    I also tested the current patch from 🐛 SQL migrations cannot be instantiated if database is not available and Node, Migrate Drupal modules are enabled Fixed . It did not make any difference.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024