-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Container.CreateIfNotExist throws exception if container exists #109
Comments
We would have to look at a specific request, In rare cases you can get a conflict if the container is in the process of being deleted. |
So is this issues solved or do you have any problems reproducing it? |
As joeg mentioned above, you can still get a conflict if a container is currently being deleted, because the API can return neither true given that it could not create the container nor false because the container will be deleted soon. You can especially hit this behavior if you delete a container and try to recreate it again immediately. If you would like us to investigate a specific request, please let us know. |
hm, this crash happened with every container we are creating new with our tool. No pending remove operation or anything else was running. I will try it again with our tool. |
According to http://social.msdn.microsoft.com/Forums/windowsazure/en-US/8480223a-8cc7-4054-919c-a32ff02d5143/createifnotexists-concurrency-safe?forum=windowsazuredata, it looks like there is an issue with CreateIfNotExists: "Storage team confirms that CreateTableIfNotExist and DeleteTableIfExist are broken in this way. They'll file a bug if one doesn't already exist. In the meantime, a good workaround is to just call CreateTable and catch the StorageClientException check for this condition:
|
2.5 years later and they still have this bug. Just wow..... |
+1 |
get\set storagevault type
Why is this closed if its still a bug? |
I would like to know why this issue was closed. I'm having the same issue with calling CreateIfNotExists within multiple hangfire jobs. |
Still an issue here as well, I'm accessing a container in parallel and also receive the 409 conflict response. This should not be closed. |
We try to create table not on each request but on AzureTableStorage instantiation. Also, added tests to prove that such change would not hurt anyone. Need only to try to build it.
I can confirm this error occurs. Please re-open. |
I can confirm this is still an issue. |
I am currently having this issue. |
I have this problem when I try and connect to my private storage container from an external (not Azure based) development computer. When I run the same code on Azure it works (obviously). Just in case anyone else runs into this... |
I am also having this issue via the .NET SDK (v.8.4) Workaround:
|
This behavior is expected and mentioned in Azure Storage Client changelog (effective for v8.0+) . Thanks, |
Thank you for following up. It's counter-intuitive to me that the method is designed to usually throw exceptions, but the workaround I mentioned above has been working fine. |
Scroll up a little to #109 (comment) |
Missed that in the email thread somehow. Thanks!
:( |
To make sure everyone is aware of the details: the approach you have suggested involves an unnecessary extra call to Storage Service which is undesirable in most cases. Currently the 409 conflict error is internally handled by SDK if the container already exists and is more performant since the need for an extra head call is removed. If based on your use-case the majority of the calls to CreateIfNotExists will be against existing containers, I would suggest moving to a single step initialization on your containers. (Please note that previously, AppInsight would report a failure if the container was created successfully which is now corrected to 409 in case the creation did not go through.) Thanks! |
Deleted my first response as I was mistaken. You're right that I was seeing the 409 Conflict errors in Application Insights vs. unhandled exceptions. I will add the caches as you recommend. |
If majority of call is against existing container (we are calling CreateIfNotExists just to make sure it's created) should we be using
It would be just one head against container or should we still always call that CreateIfNotExists? |
It's ridiculous that there's a method named |
This is happening to us as well. This issue shouldn't be closed. |
Got this message today using The suggested code fix works, but ruins the whole point of the method: |
I can confirm this is still the case, as @andyblack19 reported 6 months ago:
And I don't see ExistsAsAsync method in Azure.Storage.Blobs 12.1.0 ... Why can't we have a simple way of creating containers without throwing exception or generating error logs in App Insights, without the possibility to suppress them? Pls reopen .. |
Agreed. Having 2.39k entries of 409 from blob storage in App Insights is unnecessary. Re-open please. |
Please re-open, i see the same problem. If I delete container from portal, while running function. But before CreateIfNotExistsAsync() |
As stated 8 years ago, we're seeing this exception with containers that exists and calling
Using the latest (AFAIK, storage nuget packages seem as prolific as npm packages these days) |
I have the feeling nobody from MS is noticing this issue as it is old and already closed ... |
App insights log the 409 as an error. It just clutters up the error log now. |
Can confirm that AppInsights logs it as error too and it's a bit of hassle to weed it out the logs |
Why on earth was this issue closed despite at least 20 people confirming this issue is not fixed? Please note that the Azure ASK documentation for .NET does not mention such an exception at all! (See: https://docs.microsoft.com/en-us/dotnet/api/azure.storage.blobs.blobcontainerclient.createifnotexistsasync?view=azure-dotnet#remarks). |
@czerwinskilukasz1 please note that Azure.Blob is from the next generation of Azure SDK packages (the so called track2). This issue is about the old, track1 package. However I completely agree this issue was closed in error. It should be reopened. |
If someone still have this problem, check the minimun TLS version of the blob storage in azure, try to downgrade it, that fixed my problem. |
I also don't think that this issue should be closed, we are also getting intermittent 409 conflicts from the CreateIfNotExists call. The library seems to be checking for "ContainerAlreadyExists" in that call but the 409s are still getting thrown. It seems silly to have to check if the container exists before calling CreateIfNotExists... |
Agreed, this is still very much a problem. App Insights is flooded with 409's because of this bug. |
Having this issue trying to create private container. |
CreateIfNotExists still flooding app insights with 409s... |
Umm, this is still a major problem. Flooding logs with errors during normal operations. Ridiculous indeed. |
I also had the same problem in Feb 2022. |
Having the same issue.. The specified container already exists when calling CreateIfNotExistsAsync |
Having this same issue. We are not doing a deletion either. |
10 years on and still a bug. Well done chaps. |
Though it would be worth directing attention to this issue #25626 now it's sort of been acknowledged... |
October 2022 and still get this exception. Just thought I would chime in. |
In my case this "if" throws another warning : Azure.Storage.Blob 12.10.0 |
We are trying to create a container reference with the new 1.7.1 SDK but when the container exists it will throw an exception:
This is the exception:
The text was updated successfully, but these errors were encountered: