EnableRetryOnFailure defaults don't cover SQL Azure recommended retry period

[kierenj]

The EnableRetryOnFailure method defaults to 5 retries, max delay 30 sec, which the code comments indicate give a ~26sec total retry duration.

The SQL Azure "dealing with transient errors" documentation indicates that transient problems may list up to 1 minute. (https://docs.microsoft.com/en-us/azure/sql-database/sql-database-troubleshoot-common-connection-issues)

Should the default for EnableRetryOnFailure cover this duration?

Additionally, I found this when checking my context config code. I have EnableRetryOnFailure, but received a load of a connection timeout exceptions with the below text, on SQL Azure, last night at around midnight:

Connection Timeout Expired. The timeout period elapsed during the post-login phase.
The connection could have timed out while waiting for server to complete the login process and respond; Or it could have timed out while attempting to create multiple active connections.
This failure occurred while attempting to connect to the routing destination.
The duration spent while attempting to connect to the original server was -
[Pre-Login] initialization=24; handshake=47;
[Login] initialization=0; authentication=0;
[Post-Login] complete=9;
The duration spent while attempting to connect to this server was -
[Pre-Login] initialization=10; handshake=32;
[Login] initialization=0; authentication=0;
[Post-Login] complete=28997;
The wait operation timed out

(added some newlines for readability)

Forgive me for rolling two questions into one issue - but does this indicate that a) it retried as a part of opening this connection, but the problem took more than the 5 default retries, b) that EF Core doesn't retry this type of connection-open operation, c) that it should, but I've probably misconfigured something?

Thanks!

[ajcvickers]

@AndriySvyryd Any comments on this?

[AndriySvyryd]

I think it would be reasonable to bump up the default retry count to 6 to match the current recommendation.
I don't think EF retries this error by default. You could try increasing the timeout in the connection string.

[kierenj]

Ok, that's all understandable.

Although... this is the first time I've come across one of these "transient" problems with SQL Azure*, and out-of-the-box, the flag which I assumed was designed for this kind of cloud scenario, didn't cover the right timeout period, or cover the type of error I encountered.

I understand if it's not a part of the plan (though it would be a plus, depending on other priorities). But maybe it should be possible, maybe documented? Is there a way I can configure a retry on connection failure? I'm not sure how SQL Azure/EF's SQL client responds to connection failures. It could be that it automatically retries within the timeout. If that's what you're telling me, sorry - I'll just increase the timeout. :)

(* - I can only assume this is a transient error: I wasn't reconfiguring it at the time etc)

[AndriySvyryd]

@kierenj We do retry on failure during the connection opening, but the exception you got is not considered retryable because it's generated on the client side and you have a different mechanism to set the timeout there.
We try to handle as many transient failures as possible by default, but we don't want to swallow any exceptions that might not be transient.

[ajcvickers]

Increase retries to cover one minute.