Race condition during blob publishing

JohnTortugo commented 4 years ago

There is the possibility for a race condition during blob publishing when a build that activates two different channels that target the same blob storage. The race condition itself isn't the problem. The thing is that we want to make sure that whenever we attempt to re-publish an asset the published content and the newly one are the same.

Discussed this with @mmitche and @riarenas and possible fix is like so:

Assume the blob storage doesn't accept overrides.
Try publishing a blob. --- If publishing happens everything is fine as there was no previous blob there by assumption. --- If the blob publishing fail: -----> Check whether the published blob and the local blob has different contents. If they do show an error otherwise everything is fine.

markwilkie commented 4 years ago

Are there scenarios where we intend to use sleet moving forward?

riarenas commented 4 years ago

Not moving forward, just for servicing.

riarenas commented 4 years ago

Oh, but this talks about blobs. @JohnTortugo can you clarify if you actually mean the sleet feeds, or just publishing blobs to the storage account?

markwilkie commented 4 years ago

ping @JohnTortugo

JohnTortugo commented 4 years ago

It's for Azure Storage, not necessarily Sleet feeds. I updated the issue description.

MattGal commented 4 years ago

Asked by @markwilkie to comment here: We have lots of places where we could use code (that lives in a hacky version in Buildtools already, but I think that one downloads the storage file to diff, which is bad for perf) that does noop when trying to upload an identical blob to another, an error when the contents don't match, and uploads otherwise. Consider putting this into shared functionality.

JohnTortugo commented 4 years ago

Makes sense to me. Would be nice to have at least some links here to these places if you remember off the top of your head.

dotnet / arcade-services

Race condition during blob publishing #2539