client-s3: GetObjectCommand with ETags throws error without name or details

[terozio]

Describe the bug

When doing a GetObjectCommand with an IfNoneMatch: ETag in the request, the exception that is thrown is really unclear. It has an empty name and the message is just UnknownError.

When I tried to search documentation to understand what kind of errors I can receive from S3Client.send() I didn't really find anything.

Expected Behavior

When trying to get a file with anIfNoneMatch: ETag (where ETag is the current ETag of the file) I expected to receive an error that I can easily identify to conclude that the file in S3 has not changed after I retrieved it the last time.

Current Behavior

The error I get is:

{
  "name": "",
  "$fault": "client",
  "$metadata": {
    "httpStatusCode": 304,
    "extendedRequestId": "Q8wEKZiI/bb6oeV68jmwv3yTmrTQRi30YpbA7QzcggSRJcU27YJgJDyGBLp14NTu2n8/FNPDQj0=",
    "attempts": 1,
    "totalRetryDelay": 0
  },
  "message": "UnknownError"
}

Reproduction Steps

import { S3Client, GetObjectCommand, GetObjectCommandInput, GetObjectCommandOutput } from "@aws-sdk/client-s3";

const params: GetObjectCommandInput = {
  Bucket: 'my-bucket',
  Key: 'my-key.gz',
  IfNoneMatch: '<existing etag for the file>'
}
const command = new GetObjectCommand(params);
const s3 = new S3Client();
try {
  const resp = await s3.send(command);
} catch (e) {
  console.log(JSON.stringify(e, null, 2))
}

Possible Solution

If the received exception is as intended, there should at least be some documentation on what kind of exceptions can be thrown.

Additional Information/Context

Appears similar as #1596

SDK version used

3.105.0

Environment details (OS name and version, etc.)

Mac OS, typescript 4.7.3

[yenfryherrerafeliz]

Hi @terozio, thanks for opening an issue. I was able to reproduce the reported behavior, so that I will mark this issue to be reviewed so we can investigate it further.

Thanks!

[yenfryherrerafeliz]

I want to also share with you some information from the documentation that explains what that returned error mean. Please see below:

If-None-Match
Return the object only if its entity tag (ETag) is different from the one specified; otherwise, return a 304 (not modified) error.

Thanks!

[terozio]

I want to also share with you some information from the documentation that explains what that returned error mean. Please see below:

Hi, yes 304 is what I was expecting, but it feel that its hidden a bit deep in an UnknownError. Just as a comparison in sdk v2 it was in error.statusCode.

Just to clarify: the use case is a lambda that downloads a file from s3, caches it outside of the handler and on subsequent invocations it just checks based on the ETag the file has not changed so that it can use the file from cache instead of downloading all of it.

I tried to find information about error handling with sdk v3 but didn't find many details from this repo. Google lead me to https://aws.amazon.com/blogs/developer/service-error-handling-modular-aws-sdk-js/ and based on that article I assumed all errors would have name at least.

Furthermore the article states You can use instanceof to assert if a caught exception is expected and that lead me to wondering that how can I find out which possible exceptions for example s3client.send(GetObjectCommand) can throw so that I'm prepared to handle the correct ones.

[AllanZhengYP]

Hi @terozio

I can confirm the S3 returns a 304 with empty payload with the input you shared. In this case the SDK cannot parse a valid error code(name) from the response. In v2 SDK, we use the error status code directly. I think the same applies to the v3 SDK too.

Since this 304 error is not modeled in the service API model, the SDK doesn't generate a named error class for it, hense you cannot assert this specific error. As mentioned in the blog, it's safer to always have a fallback error assertion in the catch statements like (e instanceof S3ServiceException) {}.

I will work on a fix to populate the status case as error name, to improve the visibility of the error cause(in this case it's the 304 redirection). The caught error will look like:

{
  "name": "304",
  "$fault": "client",
  "$metadata": {
    "httpStatusCode": 304,
    "extendedRequestId": "Q8wEKZiI/bb6oeV68jmwv3yTmrTQRi30YpbA7QzcggSRJcU27YJgJDyGBLp14NTu2n8/FNPDQj0=",
    "attempts": 1,
    "totalRetryDelay": 0
  },
  "message": "UnknownError"
}

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.