Skip to content

fix: guard ConfigureDbContext() Migrate() with IHistoryRepository (Galera-safe)#2098

Merged
renemadsen merged 1 commit into
stablefrom
feat/ef-migration-helm-job
Jun 2, 2026
Merged

fix: guard ConfigureDbContext() Migrate() with IHistoryRepository (Galera-safe)#2098
renemadsen merged 1 commit into
stablefrom
feat/ef-migration-helm-job

Conversation

@renemadsen
Copy link
Copy Markdown
Member

Summary

  • Wrap Database.Migrate() in ConfigureDbContext() with an IHistoryRepository.Exists() guard to eliminate unnecessary DDL on every API pod restart

Why

On a MariaDB 11.4 Galera cluster with ~250 tenants, Database.Migrate() issues DDL (CREATE TABLE IF NOT EXISTS __EFMigrationsHistory, GET_LOCK) on every app restart even when the schema is already current. With multiple pods per tenant this causes cluster-wide desync/resync on every rolling update.

The guard pattern:

  • IHistoryRepository.Exists() — safe information_schema read, returns false if history table is absent
  • GetPendingMigrations().Any() — only called when the table exists
  • Database.Migrate() — called only when needed: fresh install, or pending migrations

In production (schema current): no DDL, no GET_LOCK. On fresh plugin activation: falls through and creates the schema.

Test Plan

  • Plugin activates from UI correctly (schema created on first activation)
  • Subsequent pod restarts do not trigger DDL when schema is current

🤖 Generated with Claude Code

Avoids DDL on every API pod restart when plugin schemas are 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>
@renemadsen renemadsen merged commit 204ab9e into stable Jun 2, 2026
14 of 18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant