Update storage package dependency version to potentially avoid BlobAlreadyExists error

[narph]

We are using the EventProcessorHost implementation in order to collect events, in some cases, when restarting the process, we see:

ERROR:
-> github.com/Azure/azure-storage-blob-go/azblob.newStorageError, /go/pkg/mod/github.com/!azure/azure-storage-blob-go@v0.8.0/azblob/zc_storage_error.go:42
===== RESPONSE ERROR (ServiceCode=BlobAlreadyExists) =====

the only solution is removing the blob storage and start the process again.

This could be related to the following issues, I am not able to find more on the potential fix:
MicrosoftDocs/azure-docs#44973
Azure/azure-sdk-for-net#19022

We see the storage package (https://github.com/Azure/azure-storage-blob-go) version has not been updated in a while https://github.com/Azure/azure-event-hubs-go/blob/fixCI/go.mod which could contain the fix.

Is it possible to update the dependency version to the latest one?

Maybe related #165

Environment

• OS: Windows
• Go version: go1.15.8 windows/amd64
• Version of Library: v3.1.2

[Nighthawk22]

I already opened an MR to do so: #237 but I am not sure whom to ping :D

[richardpark-msft]

Some updates:

1. I'm unable to reproduce this with the latest EventHubs - this is without doing the package update so I'm not able to nail down whether the submitted PR will fix it.
2. The updated dependency on azure-storage-blob appears to have an issue with certain credential types, which means our live tests for the package do not work properly.

The issues in 2) were enough that we'll have to delay doing that update. However, it wasn't clear if updating would fix this issue, and I can't reproduce this with the latest package.

However, I have noticed that this particular issue is submitted against a rather old version of the package. The current version of this package is v3.3.9, vs v3.1.2 (the version in this issue) and there were some fixes related to checkpoints between that older package and the latest.

@Nighthawk22, not sure if you're actually the submitter (with a different handle) or @narph, are you seeing this issue with the latest EventHubs package?