GitHub Enterprise Server upgrade: database schema inconsistency after migration failure

GitHub Enterprise Server performs database migrations as part of the upgrade process. In scenarios where a migration fails, the system may enter an inconsistent state where the application code is updated to the new version, but the database schema remains at the previous version.

The upgrade tool logs these failures to /var/log/enterprise-server/upgrade.log, but it does not automatically revert the schema to match the previous application version. This creates uncertainty regarding the system's ability to serve traffic or maintain data integrity while in this partial state.

Technical Constraints

• The process may lock the database for extended periods during the migration attempt.
• Rollback hooks are version-dependent and may not be present in older releases.

Does the application continue to serve traffic when a migration fails but the code update completes? What is the documented method for verifying schema consistency via the schema_migrations table before initiating a manual rollback?