After deactivating a revision, when GETing the container app properties, the deactivated revision is included

[ry0y4n]

---

This issue is a: (mark with an x)

• bug report -> please search issues before submitting
• documentation issue or request
• regression (a behavior that used to work and stopped in a new release)

Issue description

After deactivating a revision, when GETing the container app properties, the deactivated revision is included.

When creating a new revision, it is necessary to configure the revisions array so that the total traffic weight of the active revisions, including the new revision, is 100%. To do this, the container app's properties are retrieved and a new traffic is created based on the current traffic. However, if the acquired traffic array includes deactivated revisions, the total traffic weight will not be 100% because some of them are deactivated, even though the total traffic weight is configured to be 100%.

For example, suppose there are two revisions (revision-a and revision-b) with a traffic weight of 50% each.
When revision-a is deactivated, only revision-b remains with a traffic weight of 50% (this is also confusing with the fact that the total traffic must be 100% when creating a new revision). When the developer tries to create a new revision (revision-c) and retrieves the container app properties, revision-a (50%) and revision-b (50%) are included. The developer is confused by this, and decides how to set the traffic for revision-c(0%? or 50%?).

This is very confusing.

In this situation, the total traffic weight of the active revisions is only 50%, so when I access the application, I get a error with some probability (maybe 50%?). Is this an expected specification?

My questions are the following three:

• Is it OK to have already deactivated revisions in the traffic?
• Is it OK if the total weight of the traffic is not 100%?
• Is the rule that the total traffic weight must be 100% a specification that allows for disabled revisions to be included? Or is this an unexpected use?

I ran into this issue while setting up a CI/CD process that automatically creates a preview environment triggered by a pull request.

When a developer wants to automate container app updates triggered by Docker image updates with other settings inherited, the developer needs to distribute the traffic weight of the new revision based on the current traffic split. However, due to the inclusion of inactive ones, the total traffic weight of the active revisions does not total 100%, which is an error. Or, when attempting to distribute the traffic weights to the new revision based on the total active traffic weights previously checked on the portal, an error occurs because the total weights in the local traffic array do not sum up to 100%, and the deployment fails. .

This is because the specification is such that operations in the traffic array and active/inactive operations in the revision do not affect each other. In my opinion, the traffic array should not include deactivated revisions. In addition, if there is a specification that the total traffic weight of active revisions must be 100%, there may be a need for a scheme to distribute traffic to other revisions when a revision (traffic weight > 0) becomes deactivated. Otherwise, as in this case, access to the application will fail with some probability.

I believe this is an issue that many people have problems with when running in production. So I hope this issue will be addressed so that ACA, which just became GA, can successfully ride the workload of users.

Steps to reproduce

1. Create a base revision using this REST API (e.g., the traffic array as follows)

"traffic": [
  {
    "revisionName": "revision-a",
    "weight": 50
  },
  {
    "revisionName": "revision-b",
    "weight": 50
  }
]

Screenshot of Azure Portal when step 1 of reproduct is completed

2. Deactivate revision-a using this REST API
Screenshot of Azure Portal when step 2 of reproduct is completed

3. Use this REST API to get the container app properties (it contains a traffic array like this)

"traffic": [
  {
    "revisionName": "revision-a",
    "weight": 50
  },
  {
    "revisionName": "revision-b",
    "weight": 50
  }
]

In addition to above, I have been able to create a revision-c with a traffic weight of 0 as follows.

4. Using the same REST API as in step 1, create a new revision (revision-c) based on the resulting traffic array so that the total is 100% (e.g., make the traffic array as follows)

"traffic": [
  {
    "revisionName": "revision-a",
    "weight": 50
  },
  {
    "revisionName": "revision-b",
    "weight": 50
  },
  {
    "revisionName": "revision-c",
    "weight": 0
  }
]

5. Checking the Azure Portal, only revision-b (50%) and revision-c (0%) are actually active, and the total traffic is 50%.
   

---

Expected behavior [What you expected to happen.]

After deactivating a revision (revision-a), when the container app property is retrieved, the traffic array in it does not include the deactivated revision (as shown below).

"traffic": [
  {
    "revisionName": "revision-b",
    "weight": 50
  }
]

or (it could automatically update the traffic totals to 100%)

"traffic": [
  {
    "revisionName": "revision-b",
    "weight": 100
  }
]

Actual behavior [What actually happened.]

After deactivating a revision, when the container app property is retrieved, the traffic array contained in it contains the deactivated revision (as shown below).

"traffic": [
  {
    "revisionName": "revision-a", # Already deactivated
    "weight": 50
  },
  {
    "revisionName": "revision-b",
    "weight": 50
  }
]

[ruslany]

Hi @ry0y4n, thanks for reporting this issue. It is a valid bug - the deactivated revision should not participate in the traffic splits.

[maikelvanhaaren]

@ruslany any update?