From 52a1e1b6143d5839543842fa13e4673036250b93 Mon Sep 17 00:00:00 2001 From: Joseph Doherty Date: Thu, 22 Oct 2026 10:42:35 -0400 Subject: [PATCH] fix(configdb): dev auto-migrate uses a 30-min command timeout so large AuditLog index builds (ReviewRemediationIndexes on ~9M rows) and the peer's applock wait don't time out at 30 s --- .../MigrationHelper.cs | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/src/ZB.MOM.WW.ScadaBridge.ConfigurationDatabase/MigrationHelper.cs b/src/ZB.MOM.WW.ScadaBridge.ConfigurationDatabase/MigrationHelper.cs index 8f7c2ab2..3eb21e66 100644 --- a/src/ZB.MOM.WW.ScadaBridge.ConfigurationDatabase/MigrationHelper.cs +++ b/src/ZB.MOM.WW.ScadaBridge.ConfigurationDatabase/MigrationHelper.cs @@ -11,6 +11,9 @@ namespace ZB.MOM.WW.ScadaBridge.ConfigurationDatabase; /// public static class MigrationHelper { + /// Command timeout applied to the development auto-apply of migrations. + internal static readonly TimeSpan MigrationCommandTimeout = TimeSpan.FromMinutes(30); + /// /// Applies pending migrations (development mode) or validates schema version (production mode). /// @@ -34,7 +37,20 @@ public static class MigrationHelper if (isDevelopment) { - await dbContext.Database.MigrateAsync(cancellationToken); + // Index builds over a large AuditLog (millions of rows on the rig) take minutes, + // and the peer central node waits on EF's migration applock for the same span — + // the default 30 s command timeout fails both. Production applies migrations from + // the generated SQL scripts, so this only widens the dev auto-apply path. + var previousTimeout = dbContext.Database.GetCommandTimeout(); + dbContext.Database.SetCommandTimeout(MigrationCommandTimeout); + try + { + await dbContext.Database.MigrateAsync(cancellationToken); + } + finally + { + dbContext.Database.SetCommandTimeout(previousTimeout); + } } else {