Deprecations are swallowed when running commands with `Application`

[Kern046]

Hello, I'm trying to setup Foundry in my Symfony project to enjoy your amazing work !

I face an issue when using the ResetDatabase trait in my tests :

RuntimeException: Error running "doctrine:schema:update --em=default --force -v": 
 [WARNING] Not passing the "--complete" option to "doctrine:schema:update" is deprecated and will not be supported when 
           using doctrine/dbal 4 

/vendor/zenstruck/foundry/src/symfony_console.php:27
/vendor/zenstruck/foundry/src/ORM/ResetDatabase/SchemaDatabaseResetter.php:47
/vendor/zenstruck/foundry/src/ORM/ResetDatabase/SchemaDatabaseResetter.php:41
/vendor/zenstruck/foundry/src/ORM/ResetDatabase/BaseOrmResetter.php:53
/vendor/zenstruck/foundry/src/Persistence/ResetDatabase/ResetDatabaseManager.php:100
/vendor/zenstruck/foundry/src/Test/ResetDatabase.php:54

I use Foundry 2.6.1, which seems to use sufficient recent versions of both Doctrine ORM (^2.16) and DoctrineBundle (^2.10) to add this missing option without causing any harm to Foundry users.

If this is okay for you I can create a PR for this.

[nikophil]

Hi @Kern046

could you please give the output of composer info doctrine/* please?

I just need to check why this deprecation is not triggered in our CI

If you check this CI run, we're using dbal 4, and everything is fine...

[nikophil]

but... it is a RuntimeException, not a deprecation 😮

I don't understand why you have an exception, although they say it is a deprecation 🤔

[Kern046]

Here is the output of composer info doctrine/*

doctrine/annotations                1.14.4 Docblock Annotations Parser
doctrine/cache                      2.2.0  PHP Doctrine Cache library is a popular cache implementation that supports many
different drivers such as redis, memcache, apc, mongodb and others.
doctrine/collections                1.8.0  PHP Doctrine Collections library that adds additional functionality on top of PHP arrays.
doctrine/common                     3.5.0  PHP Doctrine Common project is a library that provides additional functionality that other Doctrine projects depend on such as better reflection support, proxie...
doctrine/data-fixtures              2.0.3  Data Fixtures for all Doctrine Object Managers
doctrine/dbal                       3.10.0 Powerful PHP database abstraction layer (DBAL) with many features for database schema introspection and management.
doctrine/deprecations               1.1.5  A small layer on top of trigger_error(E_USER_DEPRECATED) or PSR-3 logging with options to disable all deprecations or selectively for packages.
doctrine/doctrine-bundle            2.15.0 Symfony DoctrineBundle
doctrine/doctrine-fixtures-bundle   3.7.1  Symfony DoctrineFixturesBundle
doctrine/doctrine-migrations-bundle 3.4.2  Symfony DoctrineMigrationsBundle
doctrine/event-manager              2.0.1  The Doctrine Event Manager is a simple PHP event system that was built to be used with the various Doctrine projects.
doctrine/inflector                  2.0.10 PHP Doctrine Inflector is a small library that can perform string manipulations with regard to upper/lowercase and singular/plural forms of words.
doctrine/instantiator               2.0.0  A small, lightweight utility to instantiate objects in PHP without invoking their constructors
doctrine/lexer                      2.1.1  PHP Doctrine Lexer parser library that can be used in Top-Down, Recursive Descent Parsers.
doctrine/migrations                 3.9.1  PHP Doctrine Migrations project offer additional functionality on top of the database abstraction layer (DBAL) for versioning your database schema and easily de...
doctrine/orm                        2.20.5 Object-Relational-Mapper for PHP
doctrine/persistence                3.4.0  The Doctrine Persistence project is a set of shared interfaces and functionality that the different Doctrine object mappers share.
doctrine/sql-formatter              1.5.2  a PHP SQL highlighting library

Yeah maybe it is related to other errors that I face for now, which I intended to investigate further before annoying you with it.

I'll give you the full output maybe it will give more clarity :

/platform1 # vendor/bin/phpunit --filter DistributionTypeTest
PHPUnit 9.6.23 by Sebastian Bergmann and contributors.

Warning:       Your XML configuration validates against a deprecated schema.
Suggestion:    Migrate your XML configuration using "--migrate-configuration"!

Testing 
PHP Warning:  ini_set(): Session ini settings cannot be changed after headers have already been sent in /platform1/vendor/symfony/http-foundation/Session/Storage/Handler/NativeFileSessionHandler.php on line 49

Warning: ini_set(): Session ini settings cannot be changed after headers have already been sent in /platform1/vendor/symfony/http-foundation/Session/Storage/Handler/NativeFileSessionHandler.php on line 49
EE                                                                  2 / 2 (100%)

Time: 00:07.204, Memory: 76.50 MB

There were 2 errors:

1) App\Tests\Form\Admin\DistributionTypeTest::testValidFormSubmission
Error: Typed property Zenstruck\Foundry\Factory::$attributes must not be accessed before initialization

/platform1/vendor/zenstruck/foundry/src/Factory.php:191
/platform1/vendor/zenstruck/foundry/src/ObjectFactory.php:51
/platform1/vendor/zenstruck/foundry/src/Persistence/PersistentObjectFactory.php:232
/platform1/vendor/zenstruck/foundry/src/Persistence/PersistentProxyObjectFactory.php:41
/platform1/tests/Form/Admin/DistributionTypeTest.php:25

2) App\Tests\Form\Admin\DistributionTypeTest::testInvalidFormSubmission
RuntimeException: Error running "doctrine:schema:update --em=default --force -v": 
 [WARNING] Not passing the "--complete" option to "doctrine:schema:update" is deprecated and will not be supported when 
           using doctrine/dbal 4                                                                                        


In NativeFileSessionHandler.php line 49:
                                                                                          
  [PHPUnit\Framework\Error\Warning (2)]                                                   
  ini_set(): Session ini settings cannot be changed after headers have already been sent  
                                                                                          

Exception trace:
  at /platform1/vendor/symfony/http-foundation/Session/Storage/Handler/NativeFileSessionHandler.php:49
 PHPUnit\Util\ErrorHandler->__invoke() at /platform1/vendor/symfony/phpunit-bridge/DeprecationErrorHandler.php:133
 Symfony\Bridge\PhpUnit\DeprecationErrorHandler->handleError() at n/a:n/a
 ini_set() at /platform1/vendor/symfony/http-foundation/Session/Storage/Handler/NativeFileSessionHandler.php:49
 Symfony\Component\HttpFoundation\Session\Storage\Handler\NativeFileSessionHandler->__construct() at /platform1/var/cache/test/ContainerALNompG/getSession_Handler_NativeFileService.php:25
 ContainerALNompG\getSession_Handler_NativeFileService::do() at /platform1/var/cache/test/ContainerALNompG/App_KernelTestDebugContainer.php:855
 ContainerALNompG\App_KernelTestDebugContainer->load() at /platform1/var/cache/test/ContainerALNompG/getDoctrine_Orm_Listeners_PdoSessionHandlerSchemaListenerService.php:24
 ContainerALNompG\getDoctrine_Orm_Listeners_PdoSessionHandlerSchemaListenerService::do() at /platform1/var/cache/test/ContainerALNompG/App_KernelTestDebugContainer.php:855
 ContainerALNompG\App_KernelTestDebugContainer->load() at /platform1/vendor/symfony/dependency-injection/Container.php:404
 Symfony\Component\DependencyInjection\Container->getService() at /platform1/vendor/symfony/dependency-injection/Argument/ServiceLocator.php:40
 Symfony\Component\DependencyInjection\Argument\ServiceLocator->get() at /platform1/vendor/symfony/doctrine-bridge/ContainerAwareEventManager.php:181
 Symfony\Bridge\Doctrine\ContainerAwareEventManager->initializeListeners() at /platform1/vendor/symfony/doctrine-bridge/ContainerAwareEventManager.php:59
 Symfony\Bridge\Doctrine\ContainerAwareEventManager->dispatchEvent() at /platform1/vendor/doctrine/orm/src/Tools/SchemaTool.php:424
 Doctrine\ORM\Tools\SchemaTool->getSchemaFromMetadata() at /platform1/vendor/doctrine/orm/src/Tools/SchemaTool.php:981
 Doctrine\ORM\Tools\SchemaTool->getUpdateSchemaSql() at /platform1/vendor/doctrine/orm/src/Tools/Console/Command/SchemaTool/UpdateCommand.php:92
 Doctrine\ORM\Tools\Console\Command\SchemaTool\UpdateCommand->executeSchemaCommand() at /platform1/vendor/doctrine/orm/src/Tools/Console/Command/SchemaTool/AbstractCommand.php:44
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->doExecute() at /platform1/vendor/doctrine/orm/src/Tools/Console/CommandCompatibility.php:32
 Doctrine\ORM\Tools\Console\Command\SchemaTool\AbstractCommand->execute() at /platform1/vendor/symfony/console/Command/Command.php:326
 Symfony\Component\Console\Command\Command->run() at /platform1/vendor/symfony/console/Application.php:1096
 Symfony\Component\Console\Application->doRunCommand() at /platform1/vendor/symfony/framework-bundle/Console/Application.php:126
 Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at /platform1/vendor/symfony/console/Application.php:324
 Symfony\Component\Console\Application->doRun() at /platform1/vendor/symfony/framework-bundle/Console/Application.php:80
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /platform1/vendor/symfony/console/Application.php:175
 Symfony\Component\Console\Application->run() at /platform1/vendor/zenstruck/foundry/src/symfony_console.php:24
 Zenstruck\Foundry\runCommand() at /platform1/vendor/zenstruck/foundry/src/ORM/ResetDatabase/SchemaDatabaseResetter.php:47
 Zenstruck\Foundry\ORM\ResetDatabase\SchemaDatabaseResetter->createSchema() at /platform1/vendor/zenstruck/foundry/src/ORM/ResetDatabase/SchemaDatabaseResetter.php:41
 Zenstruck\Foundry\ORM\ResetDatabase\SchemaDatabaseResetter->doResetBeforeEachTest() at /platform1/vendor/zenstruck/foundry/src/ORM/ResetDatabase/BaseOrmResetter.php:53
 Zenstruck\Foundry\ORM\ResetDatabase\BaseOrmResetter->resetBeforeEachTest() at /platform1/vendor/zenstruck/foundry/src/Persistence/ResetDatabase/ResetDatabaseManager.php:100
 Zenstruck\Foundry\Persistence\ResetDatabase\ResetDatabaseManager::resetBeforeEachTest() at /platform1/vendor/zenstruck/foundry/src/Test/ResetDatabase.php:54
 App\Tests\Form\Admin\DistributionTypeTest::_resetDatabaseBeforeEachTest() at /platform1/vendor/phpunit/phpunit/src/Framework/TestCase.php:1216
 PHPUnit\Framework\TestCase->runBare() at /platform1/vendor/phpunit/phpunit/src/Framework/TestResult.php:729
 PHPUnit\Framework\TestResult->run() at /platform1/vendor/phpunit/phpunit/src/Framework/TestCase.php:973
 PHPUnit\Framework\TestCase->run() at /platform1/vendor/phpunit/phpunit/src/Framework/TestSuite.php:685
 PHPUnit\Framework\TestSuite->run() at /platform1/vendor/phpunit/phpunit/src/Framework/TestSuite.php:685
 PHPUnit\Framework\TestSuite->run() at /platform1/vendor/phpunit/phpunit/src/Framework/TestSuite.php:685
 PHPUnit\Framework\TestSuite->run() at /platform1/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:651
 PHPUnit\TextUI\TestRunner->run() at /platform1/vendor/phpunit/phpunit/src/TextUI/Command.php:146
 PHPUnit\TextUI\Command->run() at /platform1/vendor/phpunit/phpunit/src/TextUI/Command.php:99
 PHPUnit\TextUI\Command::main() at /platform1/vendor/phpunit/phpunit/phpunit:107
 include() at /platform1/vendor/bin/phpunit:122

doctrine:schema:update [--em EM] [--complete] [--dump-sql] [-f|--force]



/platform1/vendor/zenstruck/foundry/src/symfony_console.php:27
/platform1/vendor/zenstruck/foundry/src/ORM/ResetDatabase/SchemaDatabaseResetter.php:47
/platform1/vendor/zenstruck/foundry/src/ORM/ResetDatabase/SchemaDatabaseResetter.php:41
/platform1/vendor/zenstruck/foundry/src/ORM/ResetDatabase/BaseOrmResetter.php:53
/platform1/vendor/zenstruck/foundry/src/Persistence/ResetDatabase/ResetDatabaseManager.php:100
/platform1/vendor/zenstruck/foundry/src/Test/ResetDatabase.php:54

ERRORS!
Tests: 2, Assertions: 0, Errors: 2.

The associated code :

class DistributionTypeTest extends KernelTestCase
{
    use Factories, ResetDatabase;

    public function testValidFormSubmission(): void
    {
        static::bootKernel();

        $factory = new DistributionCategoryFactory();
        $factory->create([
            'name' => 'Category 1',
            'slug' => 'category-1',
        ]);
    }
}

class DistributionCategoryFactory extends PersistentProxyObjectFactory
{
    protected function defaults(): array|callable
    {
        return [
            'isDeleted' => false,
        ];
    }

    public static function class(): string
    {
        return DistributionCategory::class;
    }
}

If needed I can try to create a reproducer repository.

[nikophil]

If needed I can try to create a reproducer repository.

yeah please do, this would be really helpful :)

[nikophil]

if you do, don't bother about mysql and/or docker, you can use sqlite, which works without any docker config :)

[nikophil]

hey do you have this config?
https://symfonycasts.com/screencast/symfony6-upgrade/framework-bundle-recipe#codeblock-9e6558d29c

maybe that's the reason of your error

[Kern046]

Hello, thanks for your patience it took me a little time to understand the issue completely and make a simple reproducer !

My understanding of the issue is that when the SchemaDatabaseUpdater runs the doctrine:schema:update command using Symfony Application object, it remains silent as long as the command doesn't fail.

An applicative issue in my work's project causes the command to fail, which gives the full command input, along with the warning. But I think the warning is still here even when the command doesn't fail, it is just not displayed.

I would have loved to contribute to add the option and fix the warning, but I just checked the latest version of Doctrine ORM SchemaUpdater command, and it seems they changed their mind about the --complete option, choosing to delete it in Doctrine 4.0.

I guess we can close the issue then, sorry for the wasted time 😬 .

[nikophil]

Hi!

thanks for your patience

no problem, it's OSS 😁 (and we're in August 😅)

But I think the warning is still here even when the command doesn't fail, it is just not displayed.

Yeah, we already know that any deprecation/warnings is hidden in all commands run by runCommand().

On the other hand, I'm wondering how complex it would be to propagate those warning/deprec to PHPUnit 🤔

@kbond do you think this could (and should) be done?

I would have loved to contribute to add the option and fix the warning, but I just checked the latest version of Doctrine ORM SchemaUpdater command, and it seems they changed their mind about the --complete option, choosing to delete it in Doctrine 4.0.

Actually, they did not change their mind, this was part of a deprecation layer:

• they wanted to change the behavior of doctrine:schema:update in v3, but this new behavior is a BC break
• in doctrine/orm 2, they added the option and deprecate not using it, so you can still have your application working with the last v2, even if --complete breaks your app. But you need to fix it before passing to v3
• if you manage to ugprade to the last v2, and if you are "deprecation-free", you are ready for v3 🎉
• in doctrine/orm 3, the default (and only) behavior is the same thant in ORM 2 with --complete
• so they've deprecated the usage of the option in ORM 3
• and removed it in v4

(note: this is basically what Symfony does as well, and what we're also trying to do in Foundry)

Actually, I don't think we really should add this --complete option, nobody ever complained about this, and I'm a bit concerned about some BC break it could imply (see #497 (comment) where we already mentioned it)

sorry for the wasted time

no problem 😊

[kbond]

do you think this could (and should) be done?

What are you thinking, run the command directly (not via Application)?

[nikophil]

I don't even know if it is possible 🙈

What are you thinking, run the command directly (not via Application)?

what are the downside of doing this?

[kbond]

what are the downside of doing this?

I can't remember exactly but I believe I tried this originally. Also, in zenstruck/console-test I remember having some issues.

To clarify, when running via Application, deprecations are swallowed?

[nikophil]

To clarify, when running via Application, deprecations are swallowed?

I've not dug into this, but it seems that it is the case