s3 client PutObject error type changed in aws-sdk-go-v2/service/s3 v1.68.0 removing description message

[benmcclelland]

Acknowledgements

• [X] I have searched (https://github.com/aws/aws-sdk/issues?q=is%3Aissue) for past instances of this issue
• [X] I have verified all of my SDK modules are up-to-date (you can perform a bulk update with go get -u github.com/aws/aws-sdk-go-v2/...)

Describe the bug

The error type for PutObject for at least some error cases has changed from *smithy.GenericAPIError to *types.InvalidRequest which does not include the helpful error message details.

Regression Issue

• [X] Select this option if this issue appears to be a regression.

Expected Behavior

The reproducer used to generate this output previous to v1.68.0:

PutObject error type: *smithy.OperationError
PutObject error: operation error S3: PutObject, https response error StatusCode: 400, RequestID: , HostID: , api error InvalidRequest: Object is WORM protected and cannot be overwritten.
smithy.APIError type: *smithy.GenericAPIError

Current Behavior

v1.68.0 and newer now produces the following:

PutObject error type: *smithy.OperationError
PutObject error: operation error S3: PutObject, https response error StatusCode: 400, RequestID: , HostID: , InvalidRequest: 
smithy.APIError type: *types.InvalidRequest

Reproduction Steps

func PutErrTest(ctx context.Context, conf aws.Config, bucket, key string) {
	client := s3.NewFromConfig(conf)


	enabled := true
	client.CreateBucket(ctx, &s3.CreateBucketInput{
		Bucket:                     &bucket,
		ObjectLockEnabledForBucket: &enabled,
	})

	cfg := types.ObjectLockConfiguration{
		ObjectLockEnabled: types.ObjectLockEnabledEnabled,
	}

	_, err := client.PutObjectLockConfiguration(ctx, &s3.PutObjectLockConfigurationInput{
		Bucket:                  &bucket,
		ObjectLockConfiguration: &cfg,
	})
	if err != nil {
		log.Fatalf("PutObjectLockConfiguration error: %v", err)
	}

	_, err = client.PutObject(ctx, &s3.PutObjectInput{
		Key:    &key,
		Bucket: &bucket,
	})
	if err != nil {
		log.Fatalf("PutObject error: %v", err)
	}

	_, err = client.PutObjectLegalHold(ctx, &s3.PutObjectLegalHoldInput{
		Bucket: &bucket,
		Key:    &key,
		LegalHold: &types.ObjectLockLegalHold{
			Status: types.ObjectLockLegalHoldStatusOn,
		},
	})
	if err != nil {
		log.Fatalf("Set legal hold error: %v", err)
	}

	_, err = client.PutObject(ctx, &s3.PutObjectInput{
		Key:    &key,
		Bucket: &bucket,
	})

	fmt.Printf("PutObject error type: %T\n", err)
	fmt.Printf("PutObject error: %v\n", err)

	var ae smithy.APIError
	if errors.As(err, &ae) {
		fmt.Printf("smithy.APIError type: %T\n", ae)
	}
}

Possible Solution

No response

Additional Information/Context

No response

AWS Go SDK V2 Module Versions Used

go 1.23.2

require (
	github.com/aws/aws-sdk-go-v2 v1.32.6
	github.com/aws/aws-sdk-go-v2/config v1.28.6
	github.com/aws/aws-sdk-go-v2/credentials v1.17.47
	github.com/aws/aws-sdk-go-v2/service/s3 v1.71.0
	github.com/aws/smithy-go v1.22.1
)

require (
	github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream v1.6.7 // indirect
	github.com/aws/aws-sdk-go-v2/feature/ec2/imds v1.16.21 // indirect
	github.com/aws/aws-sdk-go-v2/internal/configsources v1.3.25 // indirect
	github.com/aws/aws-sdk-go-v2/internal/endpoints/v2 v2.6.25 // indirect
	github.com/aws/aws-sdk-go-v2/internal/ini v1.8.1 // indirect
	github.com/aws/aws-sdk-go-v2/internal/v4a v1.3.25 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding v1.12.1 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/checksum v1.4.6 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/presigned-url v1.12.6 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/s3shared v1.18.6 // indirect
	github.com/aws/aws-sdk-go-v2/service/sso v1.24.7 // indirect
	github.com/aws/aws-sdk-go-v2/service/ssooidc v1.28.6 // indirect
	github.com/aws/aws-sdk-go-v2/service/sts v1.33.2 // indirect
)

Compiler and Version used

go version go1.23.2 darwin/arm64

Operating System and version

os x 15.0.1

[RanVaknin]

Hi @benmcclelland,

Thanks for letting us know. It seems like that this Exception was newly added to the model even though the service was in fact sending it back already and it broke our xml error deserializer. Adding to backlog.

Thanks, Ran~