Error earlier on `azd provision`

[savannahostrowski]

When running azd up, I ran into a "Sorry we are experiencing high demand" error for Cosmos.

I saw that the provisioning of Cosmos failed minutes before the command errored out as a whole. We should probably:

• Try to error out earlier (and not continue to try to provision subsequent resources)
• Better direct users on what they need to do to try again (e.g. today, we require them to remove the .azure/ and run up again...we might want a gesture like azd env delete or similar to also wipe the variables in the .env/)

Related to #191

[ellismg]

Try to error out earlier (and not continue to try to provision subsequent resources)

The way this works internally is we submit a single request to ARM (deploy everything in main.bicep) and then wait for that operation to complete. We're at the mercy of ARM's behavior here. We could, however, detect when we've seen at least one error and then try to cancel (https://learn.microsoft.com/en-us/rest/api/resources/Deployments/Cancel) the inflight deployment. That cancel could speed things up here (we'd be giving up the opportunity to continue to provision infrastructure from the other parts of your app, and perhaps, find additional errors).

Better direct users on what they need to do to try again (e.g. today, we require them to remove the .azure/ and run up again...we might want a gesture like azd env delete or similar to also wipe the variables in the .env/)

Just checking - the need to delete the .env folder here is because what you want to do the location prompt again right, and that's hard to do?

I suspect what folks really want to do when they hit this error would be something like:

1. azd down This will delete any existing infrastructure I did provision.
2. azd env unset AZURE_LOCATION. While azd env unset or a similar command doesn't exist today, but we should probably add it? Maybe it could be spelled azd env set --delete <key> if we hated the top level now in the env namespace?
3. azd provision This causes the bicep provider to ask you for a new value of AZURE_LOCATION and I'll pick some other place.

Understanding that (2) works is sort of a jump, but we could help guide folks down this path. You could imagine something more "first class" like azd provision --reconfigure which would give the provider a chance to ask questions like AZURE_SUBSCRIPTION_ID and AZURE_LOCATION (and in the future, AZURE_RESOURCE_GROUP) next?

[rajeshkamal5050]

@ellismg can you update the minor message improvements we can do here?

[rajeshkamal5050]

@ellismg @savannahostrowski adding it to the Germanium bucket. We can pull it into iterations/sprints as part of planning.

[rajeshkamal5050]

Should be covered as part of #468