Azure / Azure/azure-rest-api-specs
ACR: creating a deleted replication always fail
- Dominant language
- TypeSpec
- Stars
- 3.1k
- Forks
- 5.9k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 444
Description
## The problem
I have a Azure container registry replication with `zoneRedundancy` enabled. The API told that it doesn't support to update (`PUT`) the `zoneRedundancy` at this point. So instead I delete it and create it again.
Following is the API sequence:
*Delete*
```
DELETE /subscriptions/0-0-0-0/resourceGroups/acctestRG-acr-1290378109238/providers/Microsoft.ContainerRegistry/registries/testacccrl89712391/replications/westus2?api-version=2021-08-01-preview
```
returns 202.
*Poll Delete LRO*
```
GET /subscriptions/0-0-0-0/providers/Microsoft.ContainerRegistry/locations/westus2/operationResults/replications-5371cf28-3e18-4844-89a8-ff01827f0bd6?api-version=2021-08-01-preview
```
returns 200.
*Create*
```
PUT /subscriptions/0-0-0-0/resourceGroups/acctestRG-acr-1290378109238/providers/Microsoft.ContainerRegistry/registries/testacccrl89712391/replications/westus2?api-version=2021-08-01-preview
```
```json
{"location":"westus2","properties":{"regionEndpointEnabled":false,"zoneRedundancy":"Disabled"},"tags":{"foo":"baz"}}
```
returns 201.
*Poll Create LRO*
```
GET /subscriptions/0-0-0-0/resourceGroups/acctestRG-acr-1290378109238/providers/Microsoft.ContainerRegistry/registries/testacccrl89712391/replications/westus2/operationStatuses/replications-656ff9b1-fd8e-4691-8a13-a21c678e0894?api-version=2021-08-01-preview
```
returns 404.
## Thoughts
A workaround for this is to wait for (e.g.) 30 seconds after polling delete succeeded and then create again. It appears that the LRO of delete is reporting as successfully done, while something else is still purging at the background, which inaccidently delete the resource meant to be created.
Contributor guide
Research direction
Start by tracing the Azure Container Registry replication DELETE and PUT long-running-operation sequence described in the issue, including the delete operation result and create operation status URLs. Compare the reported 404 after recreation with the successful 201 response and document or test the expected lifecycle. Done means a replication can be recreated after delete completion without the create operation status disappearing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- api, cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100