FrozenDependencies exception when using multiple migration configurations with ResetDatabase in mode: migrate

[alena-asocial]

I'm encountering an issue when using ResetDatabase trait with multiple Doctrine migration configuration .yaml files in mode: migrate.

I have multiple .yaml migration configuration files — one for each entity manager and corresponding database:

zenstruck_foundry:
    orm:
        reset:
            mode: migrate
            migrations:
                configurations:
                    - './config/migrations/database1.yaml'
                    - './config/migrations/database2.yaml'

Each configuration specifies a different em and migrations_paths

The Problem

When the first migration is executed, it runs successfully. However, on the second configuration, I get Doctrine FrozenDependencies exception: The dependencies are frozen and cannot be edited anymore.

Full error message from my logger:

{
  "message": "Error thrown while running command \"doctrine:migrations:migrate --configuration='./config/migrations/database2.yaml' --no-interaction\". Message: \"The dependencies are frozen and cannot be edited anymore.\"",
  "context": {
    "exception": {
      "class": "Doctrine\\Migrations\\Exception\\FrozenDependencies",
      "message": "The dependencies are frozen and cannot be edited anymore.",
      "file": "/app/vendor/doctrine/migrations/src/Exception/FrozenDependencies.php:13"
    }
  }
}

It appears that the internal container dependencies for migrations are frozen after the first migration, so when it attempts to run the second, it fails due to immutability.

I expected Foundry to sequentially run all listed migration configurations (each with its own entity manager) during database reset in test environment.

Is there a way to reset multiple databases using migration mode with separate config files for each?
Or does this require some workarounds?

[kbond]

Hmm, I've never seen that exception before. I don't have experience with a non-out-of-the-box migration setup. Does it have anything to with doctrine/migrations#1440?

[nikophil]

yeah it seems totally related. Or at least to doctrine/migrations#1432

I've never seen this exception neither... I'll try to reproduce in our testsuite and see what can be done

[nikophil]

OK, I do think this should be fixed in doctrine/migrations, see doctrine/migrations#1502

I've created a failing test case in our testsuite: #892

let's see what will be the answer in my issue in their repo...