minio/minio-dotnet

Better Exception Messages In Case Of Server Errors

warappa opened this issue · 2 comments

warappa commented

As already mentioned in #1007, the exception message in case of a server error is just a XmlSerializer error message, not the error information the server sent.

Steps To Reproduce

Please follow the steps outlined in #1007

Currently, an InvalidOperationException with

  • message: There is an error in XML document (2, 2). and
  • inner exception message <Error xmlns='http://s3.amazonaws.com/doc/2006-03-01/'> was not expected.

is raised. This gives no guidance to help spotting the cause of the problem.

Expectation

If a deserialization exception happens (error XML instead of success XML), try to deserialize the server provided error xml document with the right deserializer and pass this information on to the thrown exception.

Example error response

<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><Key>TestPut.json</Key><BucketName>bucket</BucketName><Resource>/bucket/TestPut.json</Resource><RequestId>17B3FBA079802363</RequestId><HostId>dd9025bab4ad464b049177c95eb6ebf374d3b3fd1af9251148b658df7ac2e3e8</HostId></Error>

Info

MinIO (NuGet): 6.0.2
MinIO (Server): 2024-02-06T21:36:22Z

holterbades commented

I am using the client in version 6.0.1.

It would be nice if errors would generally get handled better.
E.g. if you execute a GetObjectAsync(...) call and the server responds with something like

<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>AuthorizationHeaderMalformed</Code><Message>The authorization header is malformed; the region is wrong; expecting &#39;SOMETHING&#39;.</Message><Key>812f9d5c-d8ba-413b-b23b-4b02dcfe9723</Key><BucketName>dummy</BucketName><Resource>dummy/812f9d5c-d8ba-413b-b23b-4b02dcfe9723</Resource><Region>SOMETHING</Region><RequestId>asdf...</RequestId><HostId>asdf...</HostId></Error>

but the Exception is something like this:
Minio.Exceptions.InvalidObjectNameException: MinIO API responded with message=Invalid object name..
This makes it very hard to track down the original issue.

I think the reason of the issue is that before each request the library executes an "HEAD" request - and those requests doesn't have any response body the SDK can use to parse the cause of the error. Why does the SDK even send a "HEAD" request before each other request? Isn't this pretty inefficient?

soubhi8 commented

indeed this is needed, very difficult to debug