az webapp deployment does not exit on error

Describe the bug

We’ve noticed in some Web App deployments when running pipelines that the az webapp deployment command will raise a 500 error, but continue forward with the deploy. It does not exit.

Command Name az webapp deployment source config-zip

Errors: The following is an example straight from one of our deploys. It just “returns” the following 502, but continues onward as if the response was 202 - which is usually what we see on success. (can’t seem to capture and redirect this portion to a file?)

10:12:18 Getting scm site credentials for zip deployment 10:12:23 Starting zip deployment. This operation can take a while to complete … 10:21:46 Deployment endpoint responded with status code 502

To Reproduce:

1. Create a web app
2. turn it off, or put a blockade in the path to generate an error when deploying to it.
3. Run the following command:

• az webapp deployment source config-zip --resource-group {} --name {} --src {} --subscription {} --timeout {} --output {}

1. Add a step after to see if it executes, if it does, then that’s a problem.

Expected Behavior

When a 500 error is raised, the deployment should stop and exit.

Environment Summary

macOS-10.14.6-x86_64-i386-64bit
Python 3.8.2
Installer: HOMEBREW

azure-cli 2.3.1 *

Additional Context

I’ve tried using the generated output to parse and check for errors; exit it ourselves as a bandaid. The text generated in the error portion above does not seem to be considered stdout, I can’t capture it into a file to analyze. For instance if no 202, then exit 1.

[donovanyng]

The only reason i’m forcing the command to fail, is because it doesn’t fail out on its own if the deployment spawns a 400 response code. So you’re saying this is by design?

[panchagnula]

@donovanyng az webapp deployment command you are referring to runs an async deployment operation & starts to keep polling for the status, if you are forcing the command to fail (which seems like what you are doing here) the actual deployment operation will not be cancelled since the original call was just an async deployment call. Hope this explains your question. closing this a by design,