Question
Sulu failed upgrade: code rollback without database migration reversal
Neel Lane
0 reputation · 11 Aug 2024, 08:58 UTC
66.7K views
Loading…
0 reputation · 11 Aug 2024, 08:58 UTC
Goal: decide whether restoring Sulu application code to its pre-upgrade commit is enough to recover from a failed Composer update, or whether the database must also be returned to its pre-upgrade state.
Sulu upgrades typically run through Composer and Symfony console commands, and there is no documented built-in command that atomically rolls back a failed upgrade. Doctrine migrations applied during the update may not be reversible, so reverting composer.lock alone can leave the schema and content in an upgraded state while the code expects the previous version. Cache contents may also remain stale after any restore.
Assumption: the affected site runs a supported Sulu major version with Doctrine migrations managed through Symfony console. Whether individual migrations are marked reversible needs confirmation before a code-only restore is attempted.
35275 reputation · 11 Aug 2024, 16:40 UTC
Restoring only the codebase and composer.lock after a failed Sulu upgrade is not sufficient. Doctrine migrations applied during composer update alter the database schema and often data; the rolled-back code expects the pre-upgrade schema, causing entity mapping errors, missing columns, or constraint violations in the Sulu admin. A matching pre-upgrade database dump is required for a clean recovery.
Yes. The upgraded database contains schema changes (new tables, columns, indexes, foreign keys) and possibly data transformations that the pre-upgrade entity classes do not know about. Without restoring the database to its pre-upgrade state, the Sulu admin will throw ORM exceptions on first access.
Yes, by inspection. Examine every migration file in migrations/ that was applied after your pre-upgrade commit. Each class must implement a down() method that exactly reverses the up() changes. Empty, throwing, or partial down() methods mean the migration is irreversible — making a full database restore mandatory. Do not run doctrine:migrations:migrate prev on production to test; it can leave the database in a broken intermediate state.
No. Beyond bin/console cache:clear --env=prod, you must also:
sulubin/console doctrine:schema:validatecd assets/admin && yarn install && yarn build (or equivalent npm commands)config/packages/ matches the pre-upgrade commit — Composer Flex recipes may have modified configuration files that composer.lock does not restorecomposer.lock)composer install --no-dev --optimize-autoloader to sync vendor directorybin/console cache:clear --env=prodbin/console doctrine:schema:validatecd assets/admin && yarn install && yarn buildYou have two paths, both requiring manual work:
up() method, write compensating SQL to reverse schema/data changes, apply carefully in a transaction on a staging copy first.Does a pre-upgrade database dump (SQL dump or snapshot) exist? This single fact determines whether the safe dual-restore path is available or whether you must pursue manual migration reversal.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.