s3: Restore special error handling when requesting bucket from wrong region

[gdavison]

Describe the feature

In the AWS SDK for Go v1, there is a special error code when a bucket is requested from the incorrect region. For example, when using the region us-west-2 to access a bucket in ap-northeast-1, the following error is returned:

BucketRegionError: incorrect region, the bucket is not in 'us-west-2' region at endpoint '', bucket is in 'ap-northeast-1' region
status code: 301, request id: ****, host id: ****

However, in the AWS SDK for Go v2, there is no special handling, and the error is a smithy.GenericAPIError. Using the same example, the following error is returned:

https response error StatusCode: 301, RequestID: ****, HostID: ****, api error PermanentRedirect: The bucket you are attempting to access must be addressed using the specified endpoint. Please send all future requests to this endpoint.

The endpoint is not actually specified in the error message, though it can be extracted from the http.Response by retrieving the header X-Amz-Bucket-Region.

Use Case

Having a specific error code for this error was useful for handling it.

In addition, the error message should include the regions.

Proposed Solution

Add a new error type, for example BucketRegionError that can be returned from Deserializer middleware. At a minimum, the error message should include the correct region and the region attempted.

As an enhancement, the two regions should be added to the error struct, so that receivers of the error can make use of the information. For example

type BucketRegionError struct {
	RequestRegion string
	BucketRegion  string
}

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS Go SDK V2 Module Versions Used

github.com/aws/aws-sdk-go-v2/service/s3 v1.38.5

Go version used

go version go1.21.1 darwin/arm64

[RanVaknin]

Hi @gdavison,

Thanks for reaching out.

I see that this feature was added as a customization for v1. In v2 we strictly follow the model for generating errors.
The SDK organization as a whole has moved away from hand writing service related customizations as they are not maintainable and create feature parity gaps between major versions (like this one). The new codegen methodology is to stick to the API model published by the service team. Because of this we are not inclined to implement this feature in this point of time.

Thanks again for taking the time and submitting the request. I hope this does not discourage you from raising additional ones in the future.

All the best,
Ran~

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.