feat: remove Database.Migrate() from startup — run via Helm Job instead#7924
Merged
Conversation
…rade Job Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR changes the eFormAPI backend startup behavior to stop running EF Core migrations automatically on application startup (previously GetPendingMigrations().Any() -> Database.Migrate() in Program.MigrateDb). This aligns with the operational goal of avoiding Galera cluster DDL storms by delegating migrations to an external Helm pre-upgrade Job.
Changes:
- Removed the startup-time EF Core pending-migration check and
Database.Migrate()call for the Angular DB. - Left the remaining startup DB “maintenance/seeding” logic (menu item security group seeding, etc.) in place.
Comment on lines
200
to
202
| using var service = dbContext = scope.ServiceProvider.GetRequiredService<BaseDbContext>(); | ||
| try | ||
| { | ||
| var connectionStrings = | ||
| scope.ServiceProvider.GetRequiredService<IOptions<ConnectionStrings>>(); | ||
| if (connectionStrings.Value.DefaultConnection != "..." && dbContext.Database.GetPendingMigrations().Any()) | ||
| { | ||
| Log.LogEvent("Migrating Angular DB"); | ||
| dbContext.Database.Migrate(); | ||
| } | ||
| } | ||
| catch (Exception e) | ||
| { | ||
| var logger = scope.ServiceProvider.GetRequiredService<ILogger<Program>>(); | ||
| logger.LogError(e, "Error while migrating db"); | ||
| } | ||
|
|
||
|
|
||
| try |
…grateDb() Avoids DDL on every pod restart when schema is current (Galera-safe). Falls back to Migrate() on fresh install or when migrations are pending. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
GetPendingMigrations().Any() → Database.Migrate()block fromeFormAPI.Web/Program.csstartup pathNNN_Angularare now run by the Helm pre-upgrade Job inhelm-charts/work-items-planning-container-traefik(see microting/helm-charts#3)Why
On a MariaDB 11.4 Galera cluster, every
Database.Migrate()call at pod startup issues DDL that triggers Galera desync/resync. With 250 tenants and multiple pods per tenant, simultaneous migration checks cascade into a cluster-wide DDL storm. The Helm migration Job now handles this once per deployment.CI workflows that bootstrap the Angular DB via the app startup will no longer get migrations applied automatically. Integration tests that depend on
Program.csapplying migrations on startup will need to be updated to either call migrations directly in test setup, or run the migration bundle as part of CI setup.Test Plan
Database.Migrate()tryblock (menu item seeding) still executes correctly on startup🤖 Generated with Claude Code