I recently migrated a .NET Framework 4.6.1 application to .NET Core 2.1 and the process is crashing when the SQL AZure database becames unavailable. The process runs on Windows as a Service.
The problem itself is not the exception (it is an expected condition of SQL Azure) but the fact that I'm unable to handle the exception since it is not occurring in my code directly. It seems the exception is occurring in the SQL connection pool.
I collected the stack trace below by listening the AppDomain.CurrentDomain.UnhandledException
event:
System.Data.SqlClient.SqlException (0x80131904): Database 'XXXXXX' on server 'XXXXXX' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXX'. at new System.Data.SqlClient.SqlInternalConnectionTds(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, object providerInfo, bool redirectedUserInstance, SqlConnectionString userConnectionOptions, SessionData reconnectSessionData, bool applyTransientFaultHandling) at DbConnectionInternal System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions) at DbConnectionInternal System.Data.ProviderBase.DbConnectionFactory.CreatePooledConnection(DbConnectionPool pool, DbConnection owningObject, DbConnectionOptions options, DbConnectionPoolKey poolKey, DbConnectionOptions userOptions) at DbConnectionInternal System.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection) at void System.Data.ProviderBase.DbConnectionPool.PoolCreateRequest(object state) at bool System.Threading.ThreadPoolWorkQueue.Dispatch() ClientConnectionId:3873debc-b302-44f5-820a-8f760b1634e3 Error Number:40613,State:1,Class:14
This is not a new code and the behavior seems different when running on .NET Framework, where the process didn't stop.