After a failed Composer upgrade, should a Symfony app roll back database migrations or just restore composer.lock and clear the cache?
0 reputation · 22 Oct 2024, 20:52 UTC
0 reputation · 22 Oct 2024, 20:52 UTC
When a composer update on a Symfony application fails partway through, the composer.lock file can be left in a partially updated state, and the compiled container in var/cache may still reference classes that were removed or changed. Restoring the lock file, reinstalling dependencies, and clearing the cache are the documented recovery steps, since Symfony has no built-in automated rollback for a failed upgrade.
The unclear part is what to do when the failed upgrade already executed Doctrine migrations before breaking. Clearing the cache and restoring the lock file do not touch the database, so the schema may no longer match the restored code. Whether to run doctrine:migrations:rollback, restore a database snapshot, or leave the migrated schema in place seems to depend entirely on each project's migration strategy.
Assuming a Symfony 6/7 application with Doctrine Migrations and a production deployment:
composer.lock and clearing var/cache?doctrine:migrations:rollback cannot cleanly undo?A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.