import path of package in question: github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v0.3.0
output of go version: go version go1.17.5 linux/arm64
Using UploadStreamToBlockBlob to upload a block blob from a stream doesn't seem to work. The method returns no error, but the file doesn't appear in Azure Storage.
This is an extract of the code that I'm using, and I'm connected to an Azure Storage account running on Azure (no emulator). The connection is successful, as I'm able to, for example, create containers.
Note that in is a io.Reader readable stream, and metadata is a map[string]string.
Running the code above, I don't get any error (err is nil), and res shows a 201 response. It also contains a valid ETag. But nothing is created in the Storage Account.
PS: I have to use UploadStreamToBlockBlob rather than Upload because the stream doesn't implement a seeker (would be great if that wasn't a requirement in the first place, as that API seems more "complete").
The text was updated successfully, but these errors were encountered:
Receiving a successful HTTP status indicates that the blob was most likely created successfully. How are you checking the existence of the blob btw? If it's with the portal or Azure Storage Explorer, could you please refresh just to double check?
Please let us know and we'll open an investigation accordingly upon your confirmation. Thanks.
I've been trying to repro this outside of my own code's test environment but I can't repro it correctly yet. I'm going to close this for now assuming that's a bug in my code. Will reopen if I can create a reliable repro environment :)
@zezha-msft I figured out what the issue is. There is a bug in the SDK that I can now repro, although it's different that I originally thought. The file is created, but my tests were then deleting it because of a bug somewhere else.
In essence, when using UploadStreamToBlockBlob, the blob access conditions are ignored. You can see in my code above that I use IfNoneMatch: &ifNoneMatch to only create the blob if it doesn't exist. That was working fine with the old ("track 1") SDK, but it's not working with the new one. That caused the tests to overwrite the file, and then the next test was deleting it making it look like it was never there. I'm going to open a separate issue for that with full repro code.