-
Notifications
You must be signed in to change notification settings - Fork 212
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
Minio 6.0.2: Unexpected Behavior with Unavailable Endpoints #1041
Comments
Happens to me as well. Works with |
Also |
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 Using .Net 8, TestContainers , xUnit and 6.0.2
I'm initializing my container with
|
Response error handling was unintentionally removed in a previous commit. Added it back to the `ExecuteTaskCoreAsync` method. Fixed `NullReferenceException`-bug in the `HandleIfErrorResponse` method - `throw response.Exception;` does not make sense if the exception is null.
Response error handling was unintentionally removed in a previous commit. Added it back to the `ExecuteTaskCoreAsync` method. Fixed `NullReferenceException`-bug in the `HandleIfErrorResponse` method - `throw response.Exception;` does not make sense if the exception is null.
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
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.
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 I traced back the problem to changes in the commit 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 |
Response error handling was unintentionally removed in a previous commit. Added it back to the `ExecuteTaskCoreAsync` method. Fixed `NullReferenceException`-bug in the `HandleIfErrorResponse` method - `throw response.Exception;` does not make sense if the exception is null.
Response error handling was unintentionally removed in a previous commit. Added it back to the `ExecuteTaskCoreAsync` method. Fixed `NullReferenceException`-bug in the `HandleIfErrorResponse` method - `throw response.Exception;` does not make sense if the exception is null.
Issue Summary:
Upgrading from Minio .NET SDK version 6.0.1 to 6.0.2 has introduced unexpected behavior when interacting with non-existent Minio server endpoints. Specifically, methods like
BucketExistsAsync
andGetObjectAsync
do not behave as expected when provided with endpoints that are not running Minio servers. Instead of throwing exceptions or indicating errors, they return unexpected results, such as always returning true for bucket existence checks and returning empty streams for object downloads.Steps to Reproduce:
"127.0.0.1:11111"
).BucketExistsAsync
method to check for the existence of a bucket that doesn't exist.GetObjectAsync
method to download an object from a non-existent bucket.Expected Behavior:
Actual Behavior:
Environment Details:
The text was updated successfully, but these errors were encountered: