Azure SQL transient error

[conreaux]

We occasionally encounter a transient Azure SQL error 47073 (see definition below) in our DF application. Our IT department is investigating root cause. It can hit any DF in our app. Is this a candidate to add to the transient errors list for automatic retry? Could additional error codes be configurable?

We could add custom retry handlers to activity and sub-orchestrator functions, but that doesn't address the other cases (entities, external events, etc). Other suggestions for handling such an error (other than wrapping every DF call in a try/catch)?

Reason: Unable to set Deny Public Network Access to Yes since there is no private endpoint enabled to access the server. Please set up private endpoints and retry the operation (https://learn.microsoft.com/azure/sql-database/sql-database-private-endpoint-overview#how-to-set-up-private-link-for-azure-sql-database).

[cgillum]

@conreaux the description of 47073 sounds like it's not supposed to be transient, but you're observing it happening transiently? Do I understand that correctly?

[conreaux]

Yes, I agree that it should not be transient. However, we encounter this error intermittently and typically for a duration of 3-5 minutes. Our IT and Microsoft support are investigating, but it does seem related to DNS resolution somehow defaulting to the public endpoint even though a private endpoint is configured on the Azure SQL database (our app is running in an isolated App Service Environment). Similar issues are mentioned in this Reddit post. I understand that it probably does not fit into the transient errors list and probably not much that can be done in the MSSQL provider, but it does cause problems since any DF call can fail. Maybe just looking for error handling advice to make our app fault tolerant in cases where database errors may escape the retry logic.

[cgillum]

I think your suggestion of allowing custom status codes to be configured makes sense for a case like this. I’m supportive of this idea.