409 Conflict in copy blob should include the x-ms-copy-id

[cmaloney]

Currently when you get a 409 copy error because the target of a blobservice copy_blob API call already has a "async" copy to that target in progress, there is nothing useful inside the message. I can't tell why it failed (My code didn't know someone else did an async copy to that particular target blob). When calling copy_blob I also can't predict whether it will be synchronous or asynchronous, so I don't know when my blobs might enter the "async copy" state where all other copy operations will fail until I explicitly abort the copy...

As a small fix, would be nice if the 409 Conflict which shows up as an exception contained the "x-ms-copy-id" which would make it so my code could intelligently handle that failure. Currently all my synchronous copy code has to explicitly catch the exceptions for scenarios they never could have caused, do a get_blob_properties() call, pull out the 'x-ms-copy-id', abort the copy in progress and then retry the copy. Note that there is no timing guarantee on things like the get_blob_properties and the "cancel copy", so my subsequent calls may (depending on timing) produce a new 409 Conflict error[1]...

[1] https://msdn.microsoft.com/en-us/library/azure/jj159098.aspx "Trying to abort a copy that has completed or failed results in 409 Conflict."

[emgerner-msft]

When you get a 409 copy error because the target already has an async copy pending, you should get ‘PendingCopyOperation’ in the error information body to indicate the reason for the failure in addition to the standard 409 Conflict. This body should tell you why it failed.

While sync/async can’t be predicted with cross account copy, note that within an account copies will always be sync. Also, when start copy is initially called you will get a ‘x-ms-copy-status’ return header set to either Pending or Success. If it is Pending, you know the copy is async and if you’d like, can abort it.

So, if you’d like to abort async copies you should be able to do that immediately after the start (using x-ms-copy-status) or using the error body when the Conflict occurs.

[emgerner-msft]

Closing this issue as I haven't heard anything in a couple months. If you have any other questions or concerns in relation to this issue, please reopen it and we'll continue the discussion!