Storage: no way to list or address a specific S3 object version

Is this related to a new or existing framework?

No response

Is this related to a new or existing API?

Storage

Is this related to another service?

Amazon S3

Describe the feature you'd like to request

Storage cannot address a specific version of an S3 object, and cannot enumerate the versions of a key at all.

• The internal S3 client has no ListObjectVersions serializer
• versionId appears only as an output field on getProperties and getObject. getUrl, downloadData and copy take no versionId input

This has been asked before, in #2131 and #4746. #2131 was closed in 2021 for a specific reason, quoted here because it is the thing I am trying to answer:

versionId doesn't exist on list with S3. I'd love to gather some information on whether adding versionId to get would be useful without list and about your use cases in general.

we were trying to gather more information on what you would use this for if it was only available via the get method. We are going to close this feature request out for now as we have not heard from you on your use case. If we receive use cases where we feel its worth for us to tackle, we will look to reopen it.

Both issues are locked, so a new one seemed to be the only way to supply that.

One correction, offered gently. versionId genuinely is absent from ListObjectsV2, which is what list maps to. But S3 exposes a separate operation for this, ListObjectVersions, which returns Versions[] and DeleteMarkers[] for a prefix. So listing versions is possible; it is a different call rather than a field on the existing one. I mention it because the 2021 thread appears to have stalled on the assumption that listing was not available, and that assumption shaped the answer.

And an answer to the question that was asked. get alone is not useful. A versionId you cannot obtain is one you cannot pass, and the only way to obtain one today is out of band. ListObjectVersions is the part that makes the rest work.

Describe the solution you'd like

The smallest surface that unblocks the use case below:

1. A way to list versions of a key — either ListObjectVersions exposed directly, or an option on list that switches to it, returning versionId, lastModified, size, isLatest, and delete markers
2. versionId accepted as an input option on getUrl and downloadData

And for recovery, which is the actual point:

1. versionId on the source of copy. Restoring a previous version is a CopyObject of that version onto the same key, which is what the S3 guide recommends because it preserves the whole history rather than destroying the current version

Describe alternatives you've considered

Dropping to @aws-sdk/client-s3 alongside Amplify. This works, but it means a second S3 client, a second credential path, and losing the access-boundary model that Storage and Storage Browser provide. That is a lot to take on for one operation, and it is not available to a consumer of Storage Browser at all, which is where this came from.

I also checked whether an embeddable component elsewhere solves it. Desktop clients such as S3 Browser and Cyberduck handle versions, but they are applications rather than components. Among components, tlinhart/s3-browser and blowfishpro/react-s3-browser do not call ListObjectVersions either.

Additional context

The use case that prompted this is Amplify's own component. I opened aws-amplify/amplify-ui#7116 asking for version history in Storage Browser, and a maintainer there established that it cannot be built in that repository:

Storage Browser has no S3 client of its own. Every handler goes through storage-internal.ts, which only re-exports from @aws-amplify/storage/internals […] So even the smallest read-only scope (list versions, download one) is blocked upstream.

So the request is downstream-blocked on this package, and the two are worth reading together.

Concretely, what a user hits: versioning is a per-bucket setting an administrator enables so that end users are protected from their own mistakes. Someone uploads report.pdf over an existing report.pdf, realises it was the wrong file, and cannot get back. The previous version is sitting in the bucket. Delete is the same — with versioning on, S3 writes a delete marker rather than destroying the object, and there is no way to see it or undo it. Storage Browser even shows the version id of the current object in its preview panel, so the concept is surfaced to users as a dead end.

Is this something that you'd be interested in working on?

Yes, I'm interested in working on this — though I would want to agree on the API shape first, since it spans list, getUrl/downloadData and copy.