CI: frequent (random?) failures of InlineEntityFormCompatibilityTest in "🏚️→ 🏠 Contrib migrations Drupal 10 (next)" job

This blocks 🐛 AM:A Drush command should execute migrations as user 1, just like the UI Needs work .

Let's start with trying to stabilize the rampant DB connection issues for some of the heavier tests by leveraging #3414252-15: Add CI_DEBUG_SERVICES to investigate DB failures → .

Thanks Wim!

I'm able to recreate this test failure for inline_entity_form locally now after copying the composer.* files out of the "Artifacts" from the failed CI job.

Working my way back from that to determine specific root cause. Will follow up here.

Looks like there's a great idea here for the DB connection issues: https://www.drupal.org/project/gitlab_templates/issues/3414252#comment-1... →

2 patches from these core issues cause the IEF default widget test to fail:

1. https://www.drupal.org/project/drupal/issues/3204212 📌 Convert remaining widget and formatter type migrations to MigrateField plugins Needs work
2. https://www.drupal.org/project/drupal/issues/3108302 →

IEF expects a specific schema in migration "d7_field_instance_widget_settings" for it to map the D7 widget plugin IDs (inline_entity_form and inline_entity_form_single) to their D10 widget plugin IDs.

Because these patches change that schema, IEF no longer does this mapping and the widget is replaced to its field type's default of "entity_reference_autocomplete" and that fails the test.

Seems like there are some dependencies to solve in core before IEF could have passing tests. What do you advise for next step?

Aside from IEF and the D10 test failures, the DB connections may be causing the D9 tests to fail.

The "Contrib migrations Drupal 9 (pinned) 📌: [8.1]" job is now indicating "Connection refused" to the database before and after the change in comment 4.

Previously, this same job was failing because of a failure in bean_migrate. I downloaded the artifact for that job and ran the same tests locally and they passed. The block that's null in that job is loaded here, and it could be null if there was a database issue in a prior step. The fact that it runs fine locally and the same job is now indicating a separate DB error makes it likely the root cause is a DB issue and not specific to the logic.

Wim Leers → credited dimitriskr → .

#5: it's actually more mysterious than that. See what I wrote in the issue summary (fixed the formatting just now 🫣😅) about the test sometimes being absent. That really makes no sense because

    # Since run-test.sh does not support excluding groups: delete the files instead.
    - test "" = "$RUN_TESTS_EXCLUDE_GROUP" || find $_WEB_ROOT/modules/custom/$CI_PROJECT_NAME/tests -type f -print0 | xargs -0 grep -l "@group $RUN_TESTS_EXCLUDE_GROUP$" | xargs rm

should always find the same files, but it somehow does not! 😱

#6: Well , tests are passing on D9, but the recommendation there is:

        {
            "package": "drupal/inline_entity_form",
            "constraint": "1.0-rc11",
            "patches": {
                "Issue #3294481: Update MigrationHelper and add hook_field_migration_field_widget_info() to add widget mappings.": "https://www.drupal.org/files/issues/2022-07-06/3294481-inline_entity_form-2.patch"
            },
            "install": [
                "inline_entity_form"
            ],
            "replaces": {
                "name": "inline_entity_form"
            },
            "vetted": true
        },

— https://git.drupalcode.org/project/acquia_migrate/-/blob/recommendations...

Also see my response to #5: it's not a matter of whether IEF passes tests or not, it's a matter of why this test is not being deleted! 🙃🤪

#7: Yep, I know that's next to solve, but that's been going on for longer. I intentionally did not include that in the scope of this issue, because it's less distracting for you and @dan612 while you're working on expanding the Drupal 10 recommendations. But feel free to open a separate issue for it! Unless … unless it really is as simple as you're alluding to now. You linked to #3414252-16: Add CI_DEBUG_SERVICES to investigate DB failures → as a possible solution — I already tried something here in this MR and commented just before that over at #3414252-15: Add CI_DEBUG_SERVICES to investigate DB failures → . I'll apply that suggestion from @dimitriskr and we'll find out! 🤞

https://git.drupalcode.org/project/acquia_migrate/-/jobs/980377 didn't pass, so https://git.drupalcode.org/project/acquia_migrate/-/merge_requests/42/di... didn't make a difference.

For now … just deleting that one test during CI for D10 contrib tests seems the best approach — we should get everything out of the way that slows down progress!

https://git.drupalcode.org/project/acquia_migrate/-/merge_requests/42/di... was green for the D10 test job! 🥳

Cleaning up and merging 🚢

Automatically closed - issue fixed for 2 weeks with no activity.