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
This commit is contained in:
@@ -11,6 +11,9 @@ namespace ZB.MOM.WW.ScadaBridge.ConfigurationDatabase;
|
||||
/// </summary>
|
||||
public static class MigrationHelper
|
||||
{
|
||||
/// <summary>Command timeout applied to the development auto-apply of migrations.</summary>
|
||||
internal static readonly TimeSpan MigrationCommandTimeout = TimeSpan.FromMinutes(30);
|
||||
|
||||
/// <summary>
|
||||
/// Applies pending migrations (development mode) or validates schema version (production mode).
|
||||
/// </summary>
|
||||
@@ -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
|
||||
{
|
||||
|
||||
Reference in New Issue
Block a user