Closed rajeshkamal5050 closed 2 years ago
I don't think it's likely to be a race-condition in Azure services, given that the time between the provision and actual usage is @2 minutes apart, which is pretty lengthy. It's also pretty common for service deployments to do a config deployment, followed by an app deployment, but I have not found anyone reporting a similar issue.
I also briefly looked at the bicep file in question, and I did not see anything wrong with the app settings deployment.
Thinking out loud on some possibilities of how this could occur:
I have been seeing this as well. It is intermittent. I have discussed with the bicep team and they believe that it could be related to an RP issue. I'd like to try to test the templates w/o azd to confirm it is not related to azd. That would mean loading values from .azure/.env and calling az deployment methods directly.
@KSchlobohm can you try with the latest 0.4.0-beta.1 and see if you run into app settings issue? also @jongio recently fixed a bicep issue(config/appsettings and config/log and one was overwriting the other) in our templates.
Ken has reported that this has been resolved.
Reported offline by @KSchlobohm as below.
Second, we're seeing this issue that we've learned to monitor - https://github.com/Azure/scalable-web-app-pattern-dotnet/issues/87
In this scenario, we're seeing that the App Service and all other resources are deployed successfully but that the configuration settings on the App Service were not set. This causes the app to fail when it starts because of the missing connection string for App Configuration Service and Key Vault. The recommended step is to re-run the azd provision command.
For #87, this sounds like it could be an issue with a race condition in the Azure control plane that impacts customers more broadly than those using AZD.