DAB read requests fail with error 40613 while Azure SQL Database (serverless) is resuming

[Ryosukekoro0417 (Ryosukekoro0417)]

Read requests from Data API builder (DAB) running on Azure Container Apps to Azure SQL Database (serverless) are failing with error 40613. In each case, DAB made 3 attempts about 15 seconds apart, and the request failed after about 51.5 seconds. Changing the retry settings in the connection string (ConnectRetryCount=5) did not resolve the issue. In the DAB source code, the retry count is hardcoded as _maxRetryCount = 2.

■Environment
DAB version: 2.0.1-rc (container image)
Hosting: Azure Container Apps
Database: Azure SQL Database (serverless)

■Questions
Is the cause that DAB reached its retry limit (3 attempts)?
Can the retry count be changed through configuration in any version, including the latest version (v2.1.5)?
Without modifying the source code, what mitigation do you recommend?

Thank you for your support.

[mezy (joshwebtimestwo)]

Your three-attempt observation matches DAB's own query retry policy. I checked both v2.0.1-rc and v2.1.5: _maxRetryCount is a private field set to 2, meaning the initial attempt plus two retries. The SQL exception parser includes 40613 in its transient-error set.

ConnectRetryCount configures a different layer, the SQL client's connection resiliency. It does not replace that fixed DAB/Polly retry count. Upgrading to 2.1.5 therefore does not expose a longer DAB query retry budget: that constructor still uses the same value, and the 2.1.5 configuration schema has no SQL-query retry-count setting. The retry-policy settings under azure-key-vault apply to Key Vault operations.

One timing detail: DAB's configured backoffs in both versions are 2 seconds and 4 seconds, not 15 seconds. Time spent opening connections or waiting in the driver is additional, so the overall 51.5 seconds should not be interpreted as a 15-second Polly backoff.

For auto-resume specifically, Microsoft's serverless documentation confirms that the first connection can return 40613 while waking the database. Without changing DAB's source, the practical options are:

• Wrap the affected read-only operation in bounded client-side retries with backoff/jitter and an overall deadline that accommodates database resume plus DAB's attempts.
• If traffic timing is predictable, resume the database ahead of it and wait for a real database read to succeed before sending latency-sensitive traffic.
• If cold-start latency is unacceptable, disable auto-pause for that database, accepting the idle-compute cost.

Correlating the SQL database's resume-start/resume-complete events with the final DAB failure would confirm whether this request's budget expired before the database became ready. Error 40613 alone does not prove that auto-resume is the only cause.

This is verified against the tagged source/schema and Microsoft's documentation; I haven't run your Container Apps/SQL deployment or measured its resume time.

[Ryosukekoro0417 (Ryosukekoro0417)]

Thank you for the explanation.
We will increase _maxRetryCount in a test environment and check whether this resolves the issue.

[mezy (joshwebtimestwo)]

You're welcome, and thanks for testing it in a separate environment. If it still fails, the attempt count and total elapsed time from that run would be useful for narrowing down where it stops.

[Kamil Kaczmarek (kamilkaczmareksolutions)]

yes, it's the retry limit, and ConnectRetryCount alone can't help because of Connect Timeout

1. DAB side: _maxRetryCount = 2 is a hardcoded static, so 3 attempts total with 2^attempt backoff (2 s, then 4 s) (QueryExecutor.cs v2.1.5, policy). it's the same in 2.0.1-rc and 2.1.5, and there's no config knob for it: the only retry-policy in the config schema is for Azure Key Vault. 40613 is in DAB's transient list (MsSqlDbExceptionParser.cs), so all 3 attempts get used

2. each attempt starts with conn.OpenAsync() (L412), and that's where SqlClient's own login retry (ConnectRetryCount) runs. all of those login retries share one Connect Timeout budget, and SqlClient gives up as soon as the time left is less than ConnectRetryInterval (SqlInternalConnectionTds.cs v6.1.5, same code in 5.2.3, which 2.0.1-rc uses). with the defaults (Connect Timeout=15, ConnectRetryInterval=10, docs) there's room for one extra login per open at most, whatever ConnectRetryCount says. so ConnectRetryCount=5 changed nothing, and your numbers fit: about 15 s per open × 3 + 2 s + 4 s backoff ≈ 51 s

3. resume is "generally about one minute" (auto-pause and auto-resume), so the whole ~51 s window ends just before the database comes back

mitigation without touching the source: give each open enough time to ride out the resume, in the connection string DAB uses:

...;Connect Timeout=90;ConnectRetryCount=8;ConnectRetryInterval=10

with that, a single OpenAsync keeps retrying the login every 10 s for up to 90 s, and DAB's 3 attempts are only a fallback on top. the tradeoff is that the first request after a pause just waits (up to about a minute) instead of failing

if you can't accept that wait, avoid the pause: disable auto-pause (az sql db update -g <rg> -s <server> -n <db> --auto-pause-delay -1, overview, az sql db update), or keep the DB warm with a scheduled ping shorter than your auto-pause delay. a configurable _maxRetryCount would need a feature request

[Ryosukekoro0417 (Ryosukekoro0417)]

Thank you very much for the detailed explanation.

Initially, we had the following connection settings:
Connect Timeout=60;ConnectRetryCount=3;ConnectRetryInterval=10

After the issue occurred, we increased them to:
Connect Timeout=120;ConnectRetryCount=5;ConnectRetryInterval=20;

Unfortunately, the request still fails after approximately 51.5 seconds even with the updated settings.

[Kamil Kaczmarek (kamilkaczmareksolutions)]

the ~15 s spacing between attempts is the interesting part. with Connect Timeout=120;ConnectRetryCount=5;ConnectRetryInterval=20 a single open should be able to wait well past 15 s, so either DAB isn't running with the new string, or the 40613 doesn't come from the login

1. on Container Apps, changing a secret doesn't create a new revision, so the running replicas keep the old value until you restart the revision or deploy a new one (manage secrets). worth checking which value the replica actually sees, e.g. the env variable your dab-config.json reads with @env('...')
2. if the string is right, could you share the full exception for one attempt from the DAB log (with the stack trace) and the timestamps of the 3 attempts? if it fails inside OpenAsync, SqlClient's login retry should be doing its job and something else is off. if it fails later, when the query runs, the login retry never gets a chance and only DAB's 3 attempts apply

if it's the second case, the only options without code changes are keeping the database from pausing (az sql db update ... --auto-pause-delay -1) or a scheduled ping that wakes it up before your traffic does