azd up/deploy hangs indefinitely during App Service post-deploy status check (no overall timeout)

[hemarina]

Summary

During Terraform deployment test runs, azd up frequently gets stuck and never exits — even when the deployment itself succeeds. The agent calls azd up, the app deploys successfully, but azd keeps running until the test harness times out. This has been observed repeatedly in App Service (web app) Terraform deploy runs.

Observed behavior

• Agent invoked azd up; the app deployed successfully and was reachable (e.g. https://app-todo-web-c685hp.azurewebsites.net/).
• azd never exited the up process; the agent waited until the test run timed out.
• Logs show azd applying a few fixes after initial provision/deploy failures, then hanging on the post-deploy validation.

Trajectory: agent-metadata log

Root cause

The post-deploy "alive" validation has no overall timeout.

DeployTrackStatus in cli/azd/pkg/azsdk/zip_deploy_client.go polls Azure's Deployment Status API (GetProductionSiteDeploymentStatus) until it reports a terminal state (RuntimeSuccessful, RuntimeFailed, BuildSuccessful, BuildFailed). It polls every 3s initially, backing off to 20s after 20 polls, but runs until a terminal state is returned or the context is cancelled. If the app never reaches a terminal state (e.g. missing startup config so the runtime never reports healthy), azd hangs.

Note: there is a 20-min default timeout for the full azd deploy, but not for this specific status-tracking step.

Proposed fix

Add an overall deadline on the polling operation itself. For example, wrap the context in DeployTrackStatus:

pollCtx, cancel := context.WithTimeout(ctx, deployStatusTimeout)
defer cancel()

and use pollCtx for BeginDeployTrackStatus, poller.Poll(...), and the select. This caps the "alive" wait regardless of whether retries ever fire. Make deployStatusTimeout configurable with a sensible default.

Existing escape hatch

The per-service status check can already be skipped entirely via:

AZD_DEPLOY_{SERVICE_NAME}_SKIP_STATUS_CHECK=true

where {SERVICE_NAME} is the service name from azure.yaml, uppercased with hyphens → underscores (e.g. my-web-app → AZD_DEPLOY_MY_WEB_APP_SKIP_STATUS_CHECK=true). Since the agent independently verifies the app is working, agentic/test flows could set this to finish as soon as deployment completes.

Contributing factor / open questions

• The initially generated infrastructure appears to be missing config (e.g. the startup command), so the deployed service never reports as alive — which makes azd appear to hang forever.
• Detection / messaging: Could azd detect the missing startup config and surface a clear error rather than appearing to hang forever?
• Feedback loop: Are the post-failure fixes that the agent applies being collected to improve the infra-generation rules?

Environment / scope

• App Service (web apps) deployments via Terraform
• Affects nightly integration test runs

[vhvb1989]

The challenge for azd is to decide what would it be a good timeout for the status check.
There is a 20min timeout for azd deploy, so the status check can't use something bigger.

I would explore pulling the status check out of azd deploy and into a new azd vefiry which automatically runs at the end of azd up and which people can call if they want to check the service status after deploy. This would also help to distinguish azd errors that are because a service's configuration issue v/s azd deploy issues.
Right now, if there's an error in the statup script for the webApp, or if there is an issue in the service's source code that crashes the services and the app never starts, azd repots it as an azd deploy error.

What do you think Rick Winter (@RickWinter) Kristen Womack (@kristenwomack) tg-msft