Happens to me as well. Works with 6.0.1, breaks with 6.0.2. I am using Ubuntu 22.04 and .NET 8.

Also PutObjectAsync doesn't throw any errors in 6.0.2 .NET 8

The same. I tried to check the behavior of the driver with test containers, and got the same issue. I finally realized that the problem doesn't come from TestContainers, but from the driver.

Observed exactly that weird behavior when the endpoint is unreachable
like if the driver was talking to a "ghost" server that says yes to everything and that acts like a black hole when you upload to it.

Using .Net 8, TestContainers , xUnit and 6.0.2
service.AddMinio(configureClient => configureClient .WithEndpoint(uri) .WithCredentials(MinIoAdapter.AccessKey, MinIoAdapter.SecretKey) .WithSSL(false) .Build() );
where uri is not pointing to a running Minio instance.

await _minioClient.BucketExistsAsync(beArgs).ConfigureAwait(false);
or await _minioClient.PresignedGetObjectAsync(presignedGetObjectArgs).ConfigureAwait(false)
always returns something (with an empty container)

_minioClient.GetObjectAsync(getObjectArgs).ConfigureAwait(true)
always returns a 0 byte length memoryStream or file, even if I has uploaded an object before (with the right name)

I'm initializing my container with

_minioContainer = new MinioBuilder() .WithUsername(MinIoAdapter.AccessKey) .WithPassword(MinIoAdapter.SecretKey) .WithPortBinding(9000, true) .WithCleanUp(true) .Build();
it's also obvious when I remove the .WithUsername(MinIoAdapter.AccessKey) .WithPassword

Imho this is a critical problem and this Issue should get the name "No error handling" because there is no actual error handling active anymore.

I encountered the following issues:

When i download a file with valid bucketName and objectName but the user/access-token does not have permission to download the object (e.g. due to a policy) or a wrong region was set in the client, no exception is thrown. So i can't verify that the download failed. The funny thing is, that instead of the object-content on the storage, the xml error response gets written to the output file.

var getObject = new GetObjectArgs()
    .WithBucket(bucketName)
    .WithObject(objectName)
    .WithFile("C:\\temp\\test2.txt");
var stat = await minio.GetObjectAsync(getObject);

Similar to this example, if i stream the object content directly to another destination (e.g. another S3 object store), i also get the error message content instead of an exception streamed to the destination. Furthermore, if i encounter an exception in the streaming action like outlined below, this exception is also catched and not delegated to the user code, which also makes it impossible to handle errors.

var getObject = new GetObjectArgs()
    .WithBucket(bucketName)
    .WithObject(objectName)
    .WithCallbackStream(stream =>
    {
        throw new Exception("Error uploading file to storage.");
    });
var stat = await minio.GetObjectAsync(getObject);

Imagine you use this action to stream the blob directly to an deep archive with retention for 7 years - in this case you get files with error messages instead of your intended object content - which you can't delete because of retention policies set on the target.

The only way you could verify that an error occoured is by validating the ObjectStat.ExtraHeaders returned by GetObjectAsync(...). But this clearly can't be a solution because it is provider dependent and would be a breaking change for clients out there.

I traced back the problem to changes in the commit 9772a373b92d81808118edbdbd653d301f4502ac, but I don't know what the intention for those changes was because it's not well documented neither in the commit nor in the linked issue (#987). But the problem is, that in this commit, the method call to HandleIfErrorResponse was unintentionally removed (this method has no other calls and if this removal was intended, the method HandleIfErrorResponse should have also been removed).

I opened a PullRequest #1057 to fix this issue.

I think, the other problems mentioned in this issue should also get resolved with my fix, because this method ExecuteTaskAsync(...) -> ExecuteTaskCoreAsync(...) is the core method used by all operations.