BucketExistsAsync returns true even if it does not exist

[RoyalScribblz]

The logic for BucketExistsAsync is incorrect. All it determines is that the response Exception isn't a BucketNotFoundException. This means if you have another exception such as HttpRequestException, it responds that the bucket exists true even when it might not.

https://github.com/minio/minio-dotnet/blob/2e46392e2d254488b9297949863c517f465ed62f/Minio/ApiEndpoints/BucketOperations.cs#L83-L85

I was getting a "The SSL connection could not be established, see inner exception." and never knew until I stepped into the lib code.

[albracko]

This is not the only method that has wrong exception handling. I just lost few hours trying to figure out why BucketExistsAsync returns true, yet method ListBucketsAsync returns an object that was created with default constructor.

In my case i had wrong endpoint, but NO info about this in logs or any exception...which was harder to find out because i was testing on Gitlab CI....so had only logs available

I looked up your code, and the implementation of ExecuteTaskCoreAsync is not in-line with error handling in your API methods. All errors are basically being swallowed, leaving developers searching for a true cause why the API is not working.

[RoyalScribblz]

Yes @albracko I also experienced this with putting and getting objects, I spent a while trying to figure out why I get "" response back from getting object but turns out whole time it was never even putting anything in there in the first place as there was no connection but it swallowed exception.

[rekarpc98]

I think exception handling needs a review.

my code:

bool exists = await minioClient.BucketExistsAsync(new BucketExistsArgs().WithBucket(bucketName));

I will get true even if the minio container be down and not be accessible by any mean 🙄

[jculverwell]

Any progress on this?

[jculverwell]

Swallowing all the errors is really disappointing. I spent a whole day investigating why the Minio dotnet Client was saying it could find a bucket I couldn't see it. Thankfully I found this github issue. To find the actual issue I ended up installing the AWSSDK.S3 nuget package and using the code below. This immediately surfaced an SSL issue.

Hope you guys can get this fixed.

`using Amazon; using Amazon.S3;

public class TestMinioAWS { private readonly AmazonS3Client _s3Client;

public TestMinioAWS()
{
    var endpoint = "minio.minio-tenant.svc.cluster.local";
    var accessKey = "miniouser";
    var secretKey = "xxxxxxx";

    var config = new AmazonS3Config
    {
        AuthenticationRegion = RegionEndpoint.USEast1.SystemName, // Should match the `MINIO_REGION` environment variable.
        ServiceURL = $"https://{endpoint}", 
        ForcePathStyle = true 
    };
    _s3Client = new AmazonS3Client(
        accessKey,
        secretKey,
        config
    );
}

public async Task CreateBucket(string bucketName) {

    Log.Information("Creating Buckets");
    var buckets = await _s3Client.ListBucketsAsync();
    Log.Information("Loaded Buckets");
    foreach (var bucket in buckets.Buckets)
    {
        Log.Information(bucket.BucketName);
    }
}

} `

[apiweb]

Sorry to ask, any news about a release with the bug fix? I’m suffering from the same problem. I saw that the bug was fixed in January.

[albracko]

The bug was not fixed yet. They just resolved this ticket with an incorrect PR (already sent them an email to reopen the ticket once it's really fixed). The bug is being fixed with this PR: https://github.com/minio/minio-dotnet/pull/1141