DeleteContainer() and DeleteBlob() do not block until the operation is completed
Bug #1208351 reported by
Raphaël Badin
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Go Windows Azure Client Library |
Triaged
|
Low
|
Unassigned |
Bug Description
DeleteContainer() and DeleteBlob() (storage_base.go) both expect a http.StatusAccepted response from the server but none of them block until the operation is completed.
Changed in gwacl: | |
assignee: | nobody → Jeroen T. Vermeulen (jtv) |
status: | Triaged → In Progress |
Changed in gwacl: | |
assignee: | Jeroen T. Vermeulen (jtv) → nobody |
To post a comment you must log in.
It does not appear as if the API supports blocking on completion of these operations.
Here are the avenues I explored:
* The management API documentation shows no way to query status information for them. There is a request ID in Azure's response for these operations, but unlike the request IDs we get from the management API these have "reporting problems to Microsoft" as their only documented use:
http:// msdn.microsoft. com/en- us/library/ windowsazure/ dd573365. aspx
* Using the management API's Get Operation Status call does not seem to work on these request IDs. It returns 404: "ResourceNotFound - The operation request ID was not found."
* Whatever item is being deleted immediately becomes invisible, so it doesn't look as if we can poll for it to disappear.
The Azure documentation describes the deletion requests as "marking for deletion," and the completion we want to wait for as "garbage collection." That makes it unlikely that there is any built-in way to poll for the latter.
There are other things we could try:
* Block and retry when creation of a new item fails with a 409 (Conflict) error, because it might mean that a previous item of the same name is still being deleted.
* Rename objects to randomized names just prior to deletion, to minimize the risk of a clash on subsequent re-creation.