Detached resources not listed anymore after second deployment with the same template. Normal?

[J0F3]

Describe the bug I am not sure if I just not completely understand deployment stacks yet or if it is really something that does not work as it should in my tenant or something.

When some resources as removed form the the bicep file and then then Deployment Stack is updated with 'detatchAll' the removed resources are shown as detached resources as expected. But then after the the Deployment Stack is updated again with exactly the same template the detached resources are not shown anymore.

To Reproduce Steps to reproduce the behavior:

1. Given the following simple Bicep template:

   
   param location string = resourceGroup().location

resource storageaccount1 'Microsoft.Storage/storageAccounts@2021-02-01' = { name: 'strdeploystacktest123' location: location kind: 'StorageV2' sku: { name: 'Standard_LRS' } }

resource storageaccount2 'Microsoft.Storage/storageAccounts@2021-02-01' = { name: 'strdeploystacktest12345' location: location kind: 'StorageV2' sku: { name: 'Standard_LRS' } }

2. Create a deployment Stack with `az stack group create ... --action-on-unmanage detachAll` or `New-AzResourceGroupDeploymentStack ... -ActionOnUnmanage DetachAll `
3. Removing 'storageaccount1' resource from the Bicep file.
4. Update the Deployment Stack with `az stack group create ... --action-on-unmanage detachAll` or `New-AzResourceGroupDeploymentStack ... -ActionOnUnmanage DetachAll ` agian.
5. The Storage Account 'str12345' is shown as detached resource now just as expected. 
6. Update the Deployment Stack again. Still same command line options and same Bicep file as used on step 4.
7. The Storage Account 'str12345' is not shown as detached resource anymore. Even tough the resource itself still exists it can not be tracked with the Deployment Stack anymore. 

**Expected behavior**
I would have expected that after the Stack is updated again with an unmodified template (Step 6. above) the Deployment Stack still keeps track of the previous detached resources so that they may also be cleaned up / deleted later on trough the Deployment Stack. 

Especially when I read this section in the documentation: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deployment-stacks?tabs=azure-cli#control-detachment-and-deletion I would assume that I would be able to delete detached Resources by changing the option of 'action-on-unmange' from 'detachAll' to 'deleteResources' or 'deleteAll' and updated the Deployment Stack again (without changing the Bicep file anymore). But it seems that this is only possible on the first Deployment Stack update right after a resource is removed from the Bicep files. If I choose to detach the removed resource at this moment I will not have any option anymore to delete the detached resources by a Deployment Stack update later on. Correct?

**Screenshots**
Initial creation of the Deployment Stack. Bot Storage Account are shown as Managed:
![image](https://github.com/Azure/deployment-stacks/assets/12759579/d9255052-6fb9-4d7a-8acf-82f49acc6c2b)

Removing 'strdeploystacktest123' from the Bicep file and update the Deployment Stack ('DetachAll'). 'strdeploystacktest123' is listed as Detached as expected:
![image](https://github.com/Azure/deployment-stacks/assets/12759579/a8ed5526-ea5c-45bd-a30c-b80a4b4a06db)

Updating the Deployment Stack again with the same Bicep file and same command line parameters. 'strdeploystacktest123' is not shown anymore. This is what surprises me:
![image](https://github.com/Azure/deployment-stacks/assets/12759579/5667c013-368c-47ab-a7c5-839680a3120d)

[dantedallag]

Hey @J0F3, let me see if I can clear things up for you. When you remove a resource from a template and re-deploy the deployment stack with said updated template, you are unmanaging the resource. This means that the resource is no longer tethered to the stack. When you specify 'deleteAll', 'detachAll', or 'deleteResources', you are instructing the stack to take that action on all resources that will become unmanaged on the current operation. The detached and deleted resource lists are only a reference to that last operation and a resource can't go from managed --> detached --> deleted; it can only go from managed --> detached or deleted.

Happy to answer more questions/clarify things further or help you find a solution for your scenario if you give some more details.

[J0F3]

Hey @dantedallag

The detached and deleted resource lists are only a reference to that last operation and a resource can't go from managed --> detached --> deleted; it can only go from managed --> detached or deleted.

Ah yes, makes perfectly sense. That is what I had misunderstood. I thought the detached resources are tracked by the Deployment Stack until they get actually deleted. But it make sense that they are get in an unmanaged state and therefore are not tethered to the stack anymore.

I was just thinking about some blue/green deployment scenarios where you would create new resources in parallel and let the old ones in detached state. Once the new resources are ready and tested the old, detached resources can be deleted by specify the 'deleteResources' in the next Stack Update. But the longer I think about it I think this should probably better be solved with two Deployment Stacks.

Thank you, you helped me a lot!