After v3.4 all migrations shown as not executed in dev toolbar

[mmarton]

Bug Report

Just checked out the new release and all of my past migrations shown as not executed:

Q	A
Version	3.4.0
Previous Version if the bug is a regression	3.3.1

Summary

cache cleared, metadatastorage synced, migration table contains all 158 entry. The toolbar still shows everything as new

Current behavior

Expected behavior

How to reproduce

[greg0ire]

Here is the diff: 3.3.1...3.4.0

Maybe the change I did in MigrationsCollector.php was wrong?

Can you please dump $this->data here:

DoctrineMigrationsBundle/src/Collector/MigrationsCollector.php

Line 35 in 9872551

if ($this->data !== []) {

?

Or maybe it's the changes I did in in MigrationsFlattener.php? Can you try reverting them one by one?

[simonsolutions]

I experience the same problem after upgrade 3.3.1 to 3.4.0.

The array at line 35 of the file is an empty array.

[greg0ire]

Ok then I guess that change is not the culprit 🤔

[simonsolutions]

Then dumping in MigrationsFlattener.php:

• flattenAvailableMigrations -> dumps all available migrations
• flattenExecutedMigrations -> dumps none of the executed migrations
• (both dumps before the returns of the static functions)

[greg0ire]

Can you try following https://dev.to/greg0ire/bisecting-vendors-12kd to pinpoint the first bad commit?

[mmarton]

This was mentiont on the original issue, I just found the exact comment. Not sure if it helps, but here it is:
doctrine/migrations#1406 (comment)

[greg0ire]

Oh right, thanks for digging that up. I'll revert my MR and release 3.4.1

[simonsolutions]

As far as i have seen now:

DoctrineMigrationsBundle/src/Collector/MigrationsCollector.php

Line 43 in 9872551

$executedMigrations = $metadataStorage->getExecutedMigrations();

the function "getExecutedMigrations" from doctrine migration, the initial "$this->isInitialized" is false so an empty list is returned.

https://github.com/doctrine/migrations/blob/d7d0df5651493e34cd7b6e150381e3102ca0f992/src/Metadata/Storage/TableMetadataStorage.php#L72

[greg0ire]

Or maybe, instead of reverting, the listener could be improved to detect that we are in HTTP context. When in HTTP context, it could disable itself 🤔

Regarding Doctrine commands such as doctrine:migrations:list, maybe the condition here can be made more precise:

DoctrineMigrationsBundle/src/EventListener/SchemaFilterListener.php

Line 52 in 9872551

if (! $command instanceof DoctrineCommand) {

[simonsolutions]

Its not only about the console command, i guess. In every request the migrations are shown as not executed.
On webrequest the $command variable in that function is not dumped and called

[simonsolutions]

Then i dump this:

DoctrineMigrationsBundle/src/Collector/MigrationsCollector.php

Line 39 in 9872551

$metadataStorage = $this->dependencyFactory->getMetadataStorage();

this is the result:

[Doctrine\Migrations\Metadata\Storage\TableMetadataStorage](phpstorm://open?file=/Users/simonriedmeier/Development/Symfony/runmagix/vendor/doctrine/migrations/src/Metadata/Storage/TableMetadataStorage.php&line=38) {#3255 ▼
  -isInitialized: false
  -schemaUpToDate: false
  -schemaManager: 
Doctrine\DBAL\Schema
\
MySQLSchemaManager {#3249 ▼
    #connection: 
Doctrine\DBAL
\
Connection {[#784 ▶](https://dev-runmagix.wip/_profiler/14ecaf?panel=dump#sf-dump-1291200273-ref2784)}
    #platform: 
Doctrine\DBAL\Platforms
\
MySQL84Platform {[#789 ▶](https://dev-runmagix.wip/_profiler/14ecaf?panel=dump#sf-dump-1291200273-ref2789)}
    -defaultTableOptions: null
  }
  -platform: 
Doctrine\DBAL\Platforms
\
MySQL84Platform {[#789 ▶](https://dev-runmagix.wip/_profiler/14ecaf?panel=dump#sf-dump-1291200273-ref2789)}
  -configuration: 
Doctrine\Migrations\Metadata\Storage
\
TableMetadataStorageConfiguration {#604 ▶}
  -connection: 
Doctrine\DBAL
\
Connection {[#784 ▶](https://dev-runmagix.wip/_profiler/14ecaf?panel=dump#sf-dump-1291200273-ref2784)}
  -comparator: 
Doctrine\Migrations\Version
\
AlphabeticalComparator {#3312}
  -migrationRepository: 
Doctrine\Migrations
\
FilesystemMigrationsRepository {#3321 ▼
    -migrationsLoaded: false
    -migrations: []
    -migrationDirectories: array:1 [▶]
    -migrationFinder: 
Doctrine\Migrations\Finder
\
GlobFinder {#3317}
    -versionFactory: 
Doctrine\Migrations\Version
\
DbalMigrationFactory {#3315 ▶}
  }
}

[greg0ire]

Its not only about the console command, i guess. In every request the migrations are shown as not executed.

Yes, and again, the listener should not just listen to console events, but also to http events, and disable itself.

[simonsolutions]

Okay the __invoke function of the EventListener is called with enabled is set to true.
But onConsoleCommand is never called on a web request.

[greg0ire]

Yes. So we have to add another function (or just make disable public?), similar to onConsoleCommand, but for the web, that will fix one issue out of the two issues (the other issue I think there might be is with doctrine:migrations:list, but nobody confirmed it yet).

Related docs: https://symfony.com/doc/current/event_dispatcher.html

[eltharin]

Hi,
Same problem here, on profiler, migrations are "not executed",
A doctrine:migrations:list show good migrated date
but doctrine:make:migration show "[WARNING] You have X available migrations to execute."
if click yes, no new migration if created (if not neaded)

[greg0ire]

@eltharin can't look into it until next week, but I think the fixes should be easy, in case you want to try

[eltharin]

Ok no problem,
It's not blocking.

[eltharin]

OK, I found the problem,
In migrations, in TableMetaDataStorage, it use tableExist to see if doctrine migration table exists.
but this function in DBAL use listTableNames in AbstractSchemaManager whitch filter assert

here are my proposes:
doctrine/dbal#6729
doctrine/migrations#1484