Efcore: Allow customizing migration commands timeout.

[MicahZoltu]

Steps to reproduce

• Create an EF Code First project.
• Create a migration that has a long running query.
• Notice timeout exception.
  

  The issue

Based on this answer (http://stackoverflow.com/a/39012033/879046), there is no way to set the timeout for migrations separately from the context's usual timeout. This means that when you have _really_ long running migrations you have to turn your normal operating timout _way_ up, even though it should probably be down in the milliseconds or seconds range depending on your setup. Sadly, this means that if you want to do a big migration you have to crank up the timeout, deploy, then rollback the timeout change and deploy again (which of course will break attempting to run the migration again elsewhere).

It would be particularly nice if you could set the timeout _per migration_ as some migrations are expected to be fast and others slow.

System.Data.SqlClient.SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.ComponentModel.Win32Exception: The wait operation timed out
   --- End of inner exception stack trace ---
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
   at System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync()
   at System.Data.SqlClient.TdsParserStateObject.TryReadNetworkPacket()
   at System.Data.SqlClient.TdsParserStateObject.TryPrepareBuffer()
   at System.Data.SqlClient.TdsParserStateObject.TryReadByte(Byte& value)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout, Boolean asyncWrite)
   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite, String methodName)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommand.Execute(IRelationalConnection connection, String executeMethod, IReadOnlyDictionary`2 parameterValues, Boolean openConnection, Boolean closeConnection)
   at Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommand.ExecuteNonQuery(IRelationalConnection connection, IReadOnlyDictionary`2 parameterValues, Boolean manageConnection)
   at Microsoft.EntityFrameworkCore.Migrations.Internal.MigrationCommandExecutor.ExecuteNonQuery(IEnumerable`1 migrationCommands, IRelationalConnection connection)
   at Microsoft.EntityFrameworkCore.Migrations.Internal.Migrator.Migrate(String targetMigration)
   at Zoltu.Bags.Api.Startup.Configure(IApplicationBuilder applicationBuilder, IHostingEnvironment hostingEnvironment, ILoggerFactory loggerFactory) in C:\Users\Micah\Source\bags-api\Startup.cs:line 117

Further technical details

EF Core version: 1.0.1
Operating system: Windows 10
Visual Studio version: 2015

Other details about my project setup:

[tomchovanec]

I think it's very important to have migrations specific timeout for production.
Also it should be higher for migrations (I would propose 300s).

[IBestuzhev]

As a workaround here, is there any condition I can check to detect, if I'm running an application in normal mode vs migration mode?

There is an answer on Stack Overflow suggesting to increase the timeout for all commands in context.

I'd like to extend it and use it for migration only

public class ApplicationDbContext : DbContext
{
    public ApplicationDbContext()
    {
        if (IsMigration())
        {
            Database.SetCommandTimeout(150000);
        }
    }
    private bool IsMigration()
    { // What should I put here?
    }
}

[bricelam]

You mean at design time? (as opposed to calling DbContext.Database.Migrate() at runtime) Use IDesignTimeDbContextFactory to create your DbContext at design time. This will allow you to configure it differently for design time.

[ajcvickers]

As @bricelam stated above, the way to set the migration timeout to something different from the runtime timeout is to use an IDesignTimeDbContextFactory. Beyond this, setting the timeout per migration is not something that we think has enough value to implement.

However, we would still likely consider a well-written community contribution to do this.