CopyObjectRequest is modified in the s3 client, the source bucket/key/version fields are nullified before the intercepters

[mtheos]

In #5244, a request customizer was added that transforms the CopyObjectRequest from bucket + key + version into copySource. AIUI, this is done to match the semantics of the SDK team to the S3 team.

However, because this transformation is applied before the execution interceptors, it leads to unintuitive behaviour where the bucket/key is null in the interceptor, even though that was the API used to construct the request.

This behaviour (AFAICS) is difficult to discover without being bitten first because it's undocumented on the API. Additionally, copySource is marked as deprecated and steers you towards bucket/key/version, pushing you towards the problem.

I don't know if providing a helper to destructure the fields consistently that can evolve with the SDK is feasible (especially since the PR alludes to future transformations), but, it would be nice for us to see a stable API that doesn't change between the client and the interceptors, and I think this is a challenging customer experience as it stands.

[mahammadv]

I'm hitting similar issue. On my case, sourceBucket and sourceKey is nullified on modifyRequest, but it's there on beforeExecution. I have made it work by passing it through ExecutionAttributes, but it would be better to grab it from context.request().