"Invalid APP_KEY" error after a failed AdonisJS 5 upgrade — safe recovery path for app and migrations

While upgrading an AdonisJS 5 application, the process can fail partway through and leave the app unable to boot. One documented failure condition is the Invalid APP_KEY error thrown on startup when the .env key has an unexpected length or format, and a separate symptom is Lucid reporting that the database schema is not up to date because migrations were applied only partially.

The uncertainty is around recovery order and scope. The framework does not appear to roll back migrations automatically when an upgrade fails, so the schema can sit between two versions while the application refuses to start. It is also unclear whether fixing the APP_KEY first and then re-running migrations is sufficient, or whether partially applied migration files must be reverted manually before re-running node ace migration:run.

Assume AdonisJS 5.x with Lucid and a relational database, verified via node ace migration:list to inspect the current migration state.

1. What is the correct sequence to recover: fix APP_KEY, then inspect and re-run migrations, or revert first?
2. How can a partially applied migration batch be identified and safely undone without losing existing data?
3. Is there any built-in mechanism to detect an inconsistent schema before the server accepts requests again?