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

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 https://github.com/aws/aws-sdk-js-v3/issues/1596

SDK version used

3.105.0

Environment details (OS name and version, etc.)

Mac OS, typescript 4.7.3

[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[bot]]

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.