Container Instance No Longer Starting

[jbowser-bt]

I restarted a container instance today, and the container is now failing to start after pulling down the DAB image. I've created new container instances using mcr.microsoft.com/azure-databases/data-api-builder:1.1.7 and mcr.microsoft.com/azure-databases/data-api-builder:latest, and both instances get the same issue.

az container create -g ABC --name XYZ --image mcr.microsoft.com/azure-databases/data-api-builder:1.1.7 .......
az container create -g ABC --name XYZ --image mcr.microsoft.com/azure-databases/data-api-builder:latest .......

Edit: Worth noting that the container isn't generating any logs in the process.

Is anyone else running into this problem?

[seantleonard]

Can you provide any more info about your config:

• Which database are you using?
• Which version of dab container were you previously using?
  • If using CosmosDB, does your config work locally? I've seen some issues arise like [Bug]: GraphQL query execution fails after dab update #2266.

[jbowser-bt]

• Azure SQL Database
• When I deployed in late June, I had deployed against latest. However, after reconciling the sha, it actually deployed with 0.12.0-rc for some reason. I've since tried to redeploy against 0.12.0-rc directly, and I receive the same error with no logs being generated/captured.

I'm currently trying to pull dab back down locally with dotnet tool to see if I run into the same issues locally.

The reason for the restart was to redirect dab to a different Azure SQL Server and database. I've reverted the config back to the original server and database, and continue to receive the same error.

[jbowser-bt]

Well I lied. It works correctly after revering back to the original server and database. That gives me something to rundown. I'll share what I learn in case someone else makes whatever mistake I'm making here.

[jbowser-bt]

Well this turned out to be EBKAC. The security schema for a table was changed between the two databases, so that was causing DAB to fail on startup.

The interesting thing is I've seen DAB generate errors on startup when the entities were misconfigured (e.g. missing key fields, typos in a view name, etc.). I'm not sure why DAB wasn't logging out errors in the container on startup.