Azure / Azure/azure-cli-extensions

`az containerapp revision copy` returns provisioningState:Succeeded even if container fails to start

Open
#6,251 5 comments 1 reaction 0 assignees View on GitHub
Auto-Assign ContainerApp needs-team-attention Service Attention
Dominant language
Python
Stars
454
Forks
1.7k
Avg merge
2d 19h
Merged PRs (30d)
64

Description

### Related command
`az containerapp revision copy`

### Extension name (the extension in question)
containerapp

### Description of issue (in as much detail as possible)
Setup: container app, running in *single instance mode*.
Isssue: CDCI deploys to that container instance. If a container fails to start, `az containerapp revision copy` reports `{"provisioningState": "Succeeded"}`back, even though container failed to provision. Since success is reported back, CICD pipeline continues. It seems like revision copy worked, hence success, the goal was not successful (a new running revision).

Running in multi revision mode, `az containerapp revision activate` does the activation.

Expected outcome: deploying a revision to an container app running in single instance mode, should not return provisioningState=succeeded if deployment fails.

Repro
Create an image that throws an unhandled exception:
```csharp
if(mySettings.MyNumber==5)
throw new Exception($"Bad error by Henrik: {mySettings.MyNumber}");
app.Run();
```
Run az
```
json="$( az containerapp revision copy -n "${containerapp}" -g "${resourceGroupName}" --cpu 0.5 --memory 1.0Gi --set-env-vars MySettings__MyNumber=5 )"
echo "${json}" | jq > ./deployment_status.json
```

The only workaround which seems to be available is to inspect the response from `az containerapp revision copy` to see if `latestReadyRevisionName != latestRevisionName`. If that is the case (!=), then you still need to verify by calling `az containerapp revision list -n "${containerapp}" -g "${resourceGroupName}" ` and then again test the same properties for the lastest deployment.

```json
"latestReadyRevisionName": "xxx--su93uxl",
"latestRevisionName": "xxx--7ip72po",
```

Full script that will test if container succeeded.

```bash
resourceGroupName=somecontainertest-we23
containerapp=somecontainertestapp-we23

json="$( az containerapp revision copy -n "${containerapp}" -g "${resourceGroupName}" --cpu 0.5 --memory 1.0Gi --set-env-vars MySettings__MyNumber=1 )"
echo "${json}" | jq > ./deployment_status.json

latestRevisionName="$( echo "${json}" | jq -r .properties.latestRevisionName )"
latestReadyRevisionName="$( echo "${json}" | jq -r .properties.latestReadyRevisionName )"

provisioningStateFromNewDeployment="$( echo "${json}" | jq -r .properties.provisioningState )"
echo "copy revision \"${latestRevisionName}\" status: \"${provisioningStateFromNewDeployment}\" )"

if [ $latestRevisionName == $latestReadyRevisionName ]; then
echo $"All good! This is what i want: ${latestRevisionName},${latestReadyRevisionName}. Devops pipeline can continue."
else
echo "Issue: latestRevision is NOT the latestReadyRevisoin. That means, what was just deployed is not ready (IT SEEMS FROM THE 'az containerapp revision copy' RESPONSE ) ${latestRevisionName} ${provisioningState}"
echo "But dont trust 'az containerapp revision copy' response. Look at az containerapp revision list, and see if the container just deployed is actually ready"
revisionList="$( az containerapp revision list -n "${containerapp}" -g "${resourceGroupName}" )"
echo "${revisionList}" |jq > revisionlist.json

provisioningState="$( echo "${revisionList}" | jq ".[] | select(.name == \"${latestRevisionName}\" ) | select( .properties.active==true) | .properties.provisioningState " | sed 's/.//;s/.$//' )"

echo "${latestRevisionName} ${provisioningState}"

if [ $provisioningState != "Provisioned" ]; then

echo $"Error, latestrevision (just deployed) is not the same as latestreadyrevision. Latest: ${latestRevisionName} Ready: ${latestReadyRevisionName}"
echo $"'az containerapp revision list' ALSO failed.. Stop pipeline"
# exit 1
else
echo $"'az containerapp revision list' shows that the deployment actually succeeded. So, pipeline can continue "

fi
fi

```

-----

Contributor guide

Open the contributing guide

Research direction

Start with the `az containerapp revision copy` entry point and run the supplied single-instance repro, comparing `provisioningState`, `latestRevisionName`, and `latestReadyRevisionName`. Use `az containerapp revision list` to verify the new revision's state; done means a failed container startup is not reported as a successful deployment.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, python
Domain
cli, cloud
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.