Fix App Service deployment status hangs - #9489
Conversation
|
Azure Pipelines: Successfully started running 1 pipeline(s). 21 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
There was a problem hiding this comment.
Pull request overview
Adds bounded App Service deployment-status polling and propagates timeout warnings through deployment results.
Changes:
- Adds a five-minute inactivity timeout reset by status transitions.
- Converts timeout outcomes into successful deployments with warnings.
- Surfaces warnings in CLI and JSON deployment results.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
cli/azd/pkg/project/service_target_appservice.go |
Collects App Service warnings. |
cli/azd/pkg/project/service_models.go |
Adds structured warnings. |
cli/azd/pkg/azsdk/zip_deploy_client.go |
Implements inactivity timeout. |
cli/azd/pkg/azsdk/zip_deploy_client_test.go |
Tests timeout behavior. |
cli/azd/pkg/azapi/webapp.go |
Converts timeout errors to warnings. |
cli/azd/pkg/azapi/azure_client_linuxwebapp_test.go |
Tests warning conversion. |
cli/azd/internal/cmd/up_graph.go |
Displays warnings during azd up. |
cli/azd/internal/cmd/service_graph.go |
Adds shared warning display. |
cli/azd/internal/cmd/deploy.go |
Displays deploy warnings. |
cli/azd/docs/environment-variables.md |
Documents timeout behavior. |
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 11 out of 11 changed files in this pull request and generated no new comments.
Suppressed comments (2)
cli/azd/pkg/azsdk/zip_deploy_client.go:40
- This message describes a total terminal-status timeout, but the deadline is reset after every status transition. Direct callers of
DeployTrackStatuswould therefore get a misleading error after a period of inactivity. Report that the deployment status did not change for the timeout duration instead. [azd-code-reviewer]
func (e *DeploymentStatusTimeoutError) Error() string {
return fmt.Sprintf("app service did not report a terminal deployment status within %s", e.Timeout)
cli/azd/pkg/azsdk/zip_deploy_client_test.go:588
- This test still expects a timeout, so it does not prove that a status transition resets the deadline: an implementation that never resets
statusTrackingDeadlinecan also make three requests and satisfy every assertion here. Return a terminal success only after the original deadline but before the reset deadline, then require no error so the test fails when reset logic is removed. [azd-code-reviewer]
timeoutErr, ok := errors.AsType[*DeploymentStatusTimeoutError](err)
require.True(t, ok)
require.Equal(t, 40*time.Millisecond, timeoutErr.Timeout)
require.GreaterOrEqual(t, pollCount, 3)
📋 Prioritization NoteThanks for the contribution! The linked issue isn't in the current milestone yet. |
|
Azure Pipelines: Successfully started running 1 pipeline(s). 21 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Treat five minutes without an App Service deployment status change as a non-fatal verification timeout. Preserve explicit deployment failures and surface the timeout as a warning from azd deploy and azd up. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d0b31e7e-f0c1-430f-9533-2d7f32e2a4f0
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d0b31e7e-f0c1-430f-9533-2d7f32e2a4f0
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: d0b31e7e-f0c1-430f-9533-2d7f32e2a4f0
800d716 to
eace4c0
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 12 out of 12 changed files in this pull request and generated no new comments.
Suppressed comments (2)
cli/azd/pkg/azsdk/zip_deploy_client.go:40
- I think we need to describe this as an inactivity timeout. Both the Go doc and
Error()currently imply a five-minute total deadline for reaching a terminal state, but every observed status transition resets the deadline, so a deployment can legitimately run much longer. Aligning the type documentation and error text with the actual trigger avoids misleading callers. [azd-code-reviewer]
// DeploymentStatusTimeoutError indicates that App Service did not report a terminal deployment
// status within the verification timeout.
type DeploymentStatusTimeoutError struct {
Timeout time.Duration
cli/azd/pkg/azsdk/zip_deploy_client_test.go:551
- This does not exercise a transition between statuses observed by the polling loop. The first GET is consumed while constructing the SDK poller; the first explicit
Pollis already GET 2 and therefore returnsRuntimeStarting, solastStatusnever observesBuildInProgress. The finalpollCount >= 3also occurs without resetting the deadline. KeepBuildInProgressfor at least the first explicit poll, then require the additional poll made possible only by the reset (or inject a clock) so this regression test fails if line 403 is removed. [azd-code-reviewer]
status := armappservice.DeploymentBuildStatusBuildInProgress
if pollCount > 1 {
status = armappservice.DeploymentBuildStatusRuntimeStarting
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
Summary
azd deploy,azd up, and structured JSON outputImplementation notes
The timeout starts after the tracked zip deployment request is accepted. It measures time since the last deployment status transition rather than total elapsed time, allowing slow deployments to continue as long as App Service reports progress.
The existing production deployment status API remains the primary signal because it provides structured instance counts, errors, and failed-instance log URLs. Newer Site Status and startup-log APIs are not used because they are not yet consistently documented or available across App Service stamps.
Fixes #8687