@kensio/yulin 1.21.0 → 1.21.2

package/docs/services/s3/README.md

@@ -862,13 +862,340 @@ failures come back.
 
 ### Limitations
 
-- Object versioning is left out. Deletion removes the Object rather than writing a delete marker,
-  and `VersionId` and `MFA` are both ignored on the request.
+- `VersionId` and `MFA` are ignored on a `DeleteObjects` request. A versioned Bucket writes a delete
+  marker over each key and reports it per key under `DeleteMarker` and `DeleteMarkerVersionId`, and
+  removing a named version needs `DeleteObjectCommand`. See
+  [Object versioning](#object-versioning).
 - A request naming no Objects, or more than the thousand S3 accepts, is refused with `MalformedXML`
   before anything is deleted.
 - A Bucket using filesystem-backed storage refuses deletion. See
   [Filesystem-backed Bucket storage](#filesystem-backed-bucket-storage).
 
+## Object versioning
+
+A versioned Bucket keeps every write of a key instead of overwriting it, and answers a delete with a
+marker rather than removing anything. Turn it on with `PutBucketVersioningCommand`, or with
+`VersioningConfiguration` on an `AWS::S3::Bucket` resource.
+
+```typescript sim-s3-object-versioning
+import {
+  DeleteObjectCommand,
+  GetObjectCommand,
+  ListObjectVersionsCommand,
+  PutBucketVersioningCommand,
+  PutObjectCommand,
+} from "@aws-sdk/client-s3";
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws();
+const simS3 = simAws.s3();
+
+await simAws.cloudFormation().deployTemplate({
+  stackName: "history-stack",
+  template: {
+    Resources: {
+      HistoryBucket: {
+        Type: "AWS::S3::Bucket",
+        Properties: { BucketName: "history" },
+      },
+    },
+  },
+});
+
+// Written before the Bucket was versioned, so this one takes the null version
+// id, as it does in real S3. A template declaring VersioningConfiguration
+// gives even the first write a version id of its own instead.
+await simS3.putObject(
+  new PutObjectCommand({
+    Bucket: "history",
+    Key: "snapshots/reader-1.json",
+    Body: JSON.stringify({ words: ["好"] }),
+  }),
+);
+
+await simS3.putBucketVersioning(
+  new PutBucketVersioningCommand({
+    Bucket: "history",
+    VersioningConfiguration: { Status: "Enabled" },
+  }),
+);
+
+await simS3.putObject(
+  new PutObjectCommand({
+    Bucket: "history",
+    Key: "snapshots/reader-1.json",
+    Body: JSON.stringify({ words: [] }),
+  }),
+);
+
+// The write did not overwrite anything. Both versions are listed, newest
+// first, with IsLatest on the one a plain read answers with.
+const listed = await simS3.listObjectVersions(
+  new ListObjectVersionsCommand({ Bucket: "history", Prefix: "snapshots/" }),
+);
+
+console.log(listed.Versions?.map((version) => version.VersionId));
+// [ "<a version id>", "null" ]
+
+// Recovery is a read of the earlier version and a write of it back.
+const earlier = await simS3.getObject(
+  new GetObjectCommand({
+    Bucket: "history",
+    Key: "snapshots/reader-1.json",
+    VersionId: "null",
+  }),
+);
+
+const recovered = await Array.fromAsync(earlier.Body ?? []);
+
+await simS3.putObject(
+  new PutObjectCommand({
+    Bucket: "history",
+    Key: "snapshots/reader-1.json",
+    Body: Buffer.concat(recovered),
+  }),
+);
+
+// A delete writes a marker over the key rather than removing anything, and
+// deleting the marker by its own id brings the Object back.
+const deleted = await simS3.deleteObject(
+  new DeleteObjectCommand({
+    Bucket: "history",
+    Key: "snapshots/reader-1.json",
+  }),
+);
+
+console.log(deleted.DeleteMarker); // true
+
+await simS3.deleteObject(
+  new DeleteObjectCommand({
+    Bucket: "history",
+    Key: "snapshots/reader-1.json",
+    VersionId: deleted.VersionId,
+  }),
+);
+```
+
+`PutObjectCommand`, `CopyObjectCommand` and `CompleteMultipartUploadCommand` each report the
+`VersionId` they wrote under. `GetObjectCommand` and `HeadObjectCommand` take one and read that
+version, and report the version they read. `DeleteObjectCommand` takes one and removes that version
+for good.
+
+`ListObjectVersionsCommand` reports the Objects under `Versions` and the delete markers under
+`DeleteMarkers`, keys in ascending order and each key's versions newest first. `IsLatest` marks the
+version a read without a `VersionId` answers with. `ListObjectsV2Command` reports the current
+version of each key alone, and a key hidden behind a delete marker is absent from it.
+
+Both lists are paged together, so `MaxKeys` counts an Object and a marker alike. A truncated listing
+carries `NextKeyMarker` and `NextVersionIdMarker`, which the next request sends back as `KeyMarker`
+and `VersionIdMarker`. See [Walking a truncated listing](#walking-a-truncated-listing) for the page
+size and how to lower it.
+
+### Enabling versioning over a Bucket that already holds Objects
+
+Real S3 gives an Object written before the configuration arrived the version id `null`, and
+simulated S3 does the same. That Object is the current version of its key, reads back under the
+literal string `null`, and stays where it is when a later write pushes it out of being current.
+
+A Bucket keeping no versions still answers `ListObjectVersionsCommand`, reporting each Object once
+under the null version id and marked latest. That is what real S3 answers for an unversioned Bucket,
+and it means the operation is safe to call before deciding whether the Bucket is versioned.
+
+### Suspending versioning
+
+`Status: "Suspended"` stops new versions being made and discards none of the ones already there. An
+Object written while suspended takes the null version id and replaces whatever else holds it, so a
+run of writes shares one version between them. Every version written while versioning was enabled
+stays readable by its own id.
+
+There is no way back to unversioned. Real S3 has no request for it, and
+`GetBucketVersioningCommand` reports no status at all for a Bucket nobody has configured, which is
+what separates one from a Bucket whose versioning was suspended.
+
+### Event notifications
+
+A delete on a versioned Bucket raises `s3:ObjectRemoved:DeleteMarkerCreated` rather than
+`s3:ObjectRemoved:Delete`, carrying the marker's version id. Removing a version by its own id raises
+`s3:ObjectRemoved:Delete` with that version id. A record from a versioned Bucket carries
+`s3.object.versionId`, and one from a Bucket without versioning leaves the field out.
+
+### Limitations
+
+- MFA delete is refused with `NotImplemented` rather than stored. Nothing here could enforce it, and
+  a Bucket reporting a protection it does not apply is worse than one that says so. `MFADelete:
+"Disabled"` is taken, and any other value is refused with `InvalidArgument`.
+- A `versionId` in a `CopySource` is still refused with `NotImplemented`. A copy reads the current
+  version.
+- `NoncurrentVersionTransitions` is stored and unread, because storage classes are left out. An
+  `Expiration` rule expires the current version behind a delete marker, as real S3 does, and raises
+  nothing. A `NoncurrentVersionExpiration` rule bounds the history, and `ExpiredObjectDeleteMarker`
+  removes a marker left bare. See
+  [Bounding the history a versioned Bucket keeps](#bounding-the-history-a-versioned-bucket-keeps).
+- The `?versioning` and `?versions` sub-resources are refused over the served S3 REST endpoint.
+  Versioning is reachable through the SDK and through a template.
+- A Bucket mounted on a filesystem directory refuses the deletion a delete marker asks for, the way
+  it refuses `DeleteObject`. See [Filesystem-backed Bucket storage](#filesystem-backed-bucket-storage).
+
+## Object Lock
+
+Object Lock holds a version of an Object against a delete. A version can be held by a retention
+period, by a legal hold or by both, and a delete naming a held version is answered with
+`AccessDenied`. One way past exists and it is narrow. A `GOVERNANCE` retention period gives way to a
+request carrying `BypassGovernanceRetention` from a caller allowed to use it. A `COMPLIANCE` period
+and a legal hold hold against everyone, the account root included. Turn it on with `PutObjectLockConfigurationCommand`, or with
+`ObjectLockEnabled` on an `AWS::S3::Bucket` resource.
+
+Object Lock holds a version, and versioning has to be on underneath it. Turning it on over a Bucket
+with versioning off is refused with `InvalidBucketState`, as real S3 refuses it, and a template
+declaring Object Lock without `VersioningConfiguration` fails the stack. See
+[Object versioning](#object-versioning) for what versioning itself changes.
+
+```typescript sim-s3-object-lock
+/**
+ * A reader's history in a Bucket nothing in the account can delete from.
+ */
+
+import {
+  DeleteObjectCommand,
+  HeadObjectCommand,
+  PutObjectCommand,
+} from "@aws-sdk/client-s3";
+
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws();
+const simS3 = simAws.s3();
+
+// Versioning goes on underneath Object Lock. Every version written into this
+// Bucket is then retained for seven days from the write.
+const stack = await simAws.cloudFormation().deployTemplate({
+  stackName: "history-stack",
+  template: {
+    Resources: {
+      HistoryBucket: {
+        Type: "AWS::S3::Bucket",
+        Properties: {
+          BucketName: "reader-history",
+          VersioningConfiguration: { Status: "Enabled" },
+          ObjectLockEnabled: true,
+          ObjectLockConfiguration: {
+            ObjectLockEnabled: "Enabled",
+            Rule: { DefaultRetention: { Mode: "COMPLIANCE", Days: 7 } },
+          },
+        },
+      },
+    },
+  },
+});
+await stack.waitForDeployComplete();
+
+const written = await simS3.putObject(
+  new PutObjectCommand({
+    Bucket: "reader-history",
+    Key: "events/reader-1.json",
+    Body: JSON.stringify({ words: ["好"] }),
+  }),
+);
+
+const held = await simS3.headObject(
+  new HeadObjectCommand({
+    Bucket: "reader-history",
+    Key: "events/reader-1.json",
+    VersionId: written.VersionId,
+  }),
+);
+
+console.log(held.ObjectLockMode); // "COMPLIANCE"
+
+try {
+  await simS3.deleteObject(
+    new DeleteObjectCommand({
+      Bucket: "reader-history",
+      Key: "events/reader-1.json",
+      VersionId: written.VersionId,
+      BypassGovernanceRetention: true,
+    }),
+  );
+} catch (error) {
+  // AccessDenied. A compliance period gives way to nobody, and naming the
+  // bypass changes nothing.
+  console.log((error as Error).name);
+}
+
+// The period lapses because simulated time passed it.
+await simAws.clock().advanceBy({ days: 8 });
+
+await simS3.deleteObject(
+  new DeleteObjectCommand({
+    Bucket: "reader-history",
+    Key: "events/reader-1.json",
+    VersionId: written.VersionId,
+  }),
+);
+```
+
+The retention boundary is a pure function of simulated time, read off the clock every time a delete
+asks. Advancing the clock past `RetainUntilDate` is all a test does to watch a held version become
+deletable. See [Controlling time](https://yulinsim.dev/time/ "Controlling time").
+
+`GetObject` and `HeadObject` report `ObjectLockMode` and `ObjectLockRetainUntilDate` for a version
+under a retention period, and `ObjectLockLegalHoldStatus` for one under a hold. A version free of
+both leaves all three out.
+
+### Retention modes
+
+`GOVERNANCE` and `COMPLIANCE` differ over who can get out of them. A governance period gives way to a
+delete carrying `BypassGovernanceRetention` from a caller holding `s3:BypassGovernanceRetention`,
+which sim IAM authorizes as a decision of its own alongside the `s3:DeleteObject` the delete already
+needed. Holding the permission and using it are separate. A delete that leaves the flag off is
+refused whatever the caller may do.
+
+A compliance period gives way to nobody, the account root included. `PutObjectRetentionCommand`
+follows the same split. A compliance period can be extended in the same mode and that is all, since
+shortening one would end the guarantee early and turning one into a governance period would hand the
+version to the first caller holding the bypass permission. A governance period can be shortened, or
+turned into a compliance one, by a request that bypasses it.
+
+### Legal holds
+
+`PutObjectLegalHoldCommand` turns the hold on a version on and off. A hold has no period to wait out.
+Only a `Status: "OFF"` takes one off, which is what makes a hold the thing to reach for when the end
+of the retention is unknowable in advance. A version can carry a hold and a retention period at
+once, and either one on its own refuses the delete.
+
+### Default retention
+
+A `DefaultRetention` under `Rule` retains every version written after it, counted from the write, so
+two versions of one key written a day apart are held until two different instants. It takes `Days` or
+`Years` and refuses both together, a year is 365 days, and the longest one real S3 takes is a hundred
+years. A Bucket with Object Lock on and no
+default leaves each version to whatever requests name it.
+
+### From a CloudFormation template
+
+`ObjectLockEnabled` and `ObjectLockConfiguration` are applied through
+`PutObjectLockConfigurationCommand`, so a template and an SDK caller are validated identically. CDK's
+`objectLockEnabled` and `objectLockDefaultRetention` synthesise both. `ObjectLockConfiguration`
+without `ObjectLockEnabled: true` fails the resource, as real CloudFormation refuses it, because a
+Bucket created around the property would report a default retention it never applied.
+
+### Limitations
+
+- `GetObjectRetentionCommand` and `GetObjectLegalHoldCommand` are absent. A version reports both
+  through `GetObject` and `HeadObject`.
+- `PutObjectCommand` takes no `ObjectLockMode`, `ObjectLockRetainUntilDate` or
+  `ObjectLockLegalHoldStatus`. A version is held by the Bucket's default retention and by
+  `PutObjectRetentionCommand` and `PutObjectLegalHoldCommand` afterwards.
+- `CreateBucketCommand` takes no `ObjectLockEnabledForBucket`. Turn versioning on, then Object Lock.
+- `DeleteObjectsCommand` names keys and no versions, so a batch delete writes delete markers and
+  reaches no held version. See [Deleting Objects](#deleting-objects).
+- The `?object-lock`, `?retention` and `?legal-hold` sub-resources are refused over the served S3
+  REST endpoint. Object Lock is reachable through the SDK and through a template.
+- A Bucket policy setting minimum and maximum allowable retention periods is left out. The only
+  bound applied is the hundred years real S3 caps a `DefaultRetention` at. A `RetainUntilDate` on a
+  single version is taken as given, however far ahead it names.
+- `S3 Batch Operations` applying retention across a manifest is left out.
+
 ## Event notifications
 
 A simulated S3 Bucket can notify a simulated Lambda function, a simulated SQS queue or a simulated
@@ -1667,8 +1994,8 @@ writes fall outside it. Without that, the simulation stops after a thousand deli
 - `eventVersion` is the version the S3 event message structure page documents now. AWS increments the
   minor version whenever it adds a field, so compare the major for equality and leave the whole
   string alone.
-- `versionId` is absent from every record, as it is on real S3 for a Bucket without versioning.
-  Versioning is left out.
+- `versionId` is absent from a record raised by a Bucket without versioning, as it is on real S3,
+  and carried by one from a versioned Bucket. See [Object versioning](#object-versioning).
 - A notification cannot be configured on a standalone `SimS3`. It has no other simulated services to
   notify, and no shared background scheduler for `backgroundTasksComplete()` to drain. Reach
   simulated S3 through `SimAws` instead.
@@ -1694,10 +2021,12 @@ writes fall outside it. Without that, the simulation stops after a thousand deli
 
 ## Buckets from CloudFormation
 
-An `AWS::S3::Bucket` resource carries five properties simulated S3 acts on. Those are `BucketName`,
-`LifecycleConfiguration`, `NotificationConfiguration`, `PublicAccessBlockConfiguration` and
+An `AWS::S3::Bucket` resource carries eight properties simulated S3 acts on. Those are `BucketName`,
+`LifecycleConfiguration`, `NotificationConfiguration`, `ObjectLockConfiguration`,
+`ObjectLockEnabled`, `PublicAccessBlockConfiguration`, `VersioningConfiguration` and
 `WebsiteConfiguration`. See [Lifecycle configuration](#lifecycle-configuration) for the parts of a
-rule that are read.
+rule that are read, [Object versioning](#object-versioning) for what versioning a Bucket changes, and
+[Object Lock](#object-lock) for what holds a version once it is written.
 
 A Bucket with no `BucketName` is named from the stack name, the logical ID and a tail derived from
 both, lower cased as a bucket name has to be. A `SiteBucket` in `orders-stack` becomes
@@ -1708,15 +2037,27 @@ cover how the stack name and the logical ID share what is left.
 Any other property is left out and recorded in
 [`stack.ignoredProperties`](https://yulinsim.dev/services/cloudformation/#properties-a-resource-was-created-without),
 and the Bucket is created and the stack carries on. That matters because a Bucket deployed without
-the versioning, replication or CORS configuration its template asked for looks configured and
+the replication or CORS configuration its template asked for looks configured and
 behaves as though it were bare, and the failure that causes turns up somewhere else entirely. The
 record is where a test checks which of those it is standing on. A property name `AWS::S3::Bucket`
 never had is recorded the same way, and a typo leaves the stack standing.
 
-One of the five given in the wrong shape still fails the stack, and so does a `BucketName` that is
+One of the eight given in the wrong shape still fails the stack, and so does a `BucketName` that is
 something other than a string. There is no Bucket to create under a name nothing else in the
 template refers to.
 
+A `ReplicationConfiguration` fails the stack as well, for a different reason. Replication is not
+simulated and nothing acts on the property, and the value is still read for the constraints real S3
+enforces on it. Those are a `Metrics.EventThreshold` with no `ReplicationTime` at `Status: Enabled`,
+a rule stating a `Filter` without the `DeleteMarkerReplication`, `Priority` and `Status` that S3
+requires alongside one, and a source Bucket whose template never enabled versioning. Real S3 answers
+each of them with a 400 and CloudFormation rolls the stack back, and the CloudFormation resource
+schema states none of them, so cfn-lint passes a template carrying any one. A deploy here that
+reported them as working would be the last check between a repository and that rollback.
+
+A configuration passing all three is recorded like any other skipped property. One that fails takes
+the Bucket with it and is never recorded, because the Resource is refused before it is created.
+
 `BucketEncryption` and `Tags` are read, ignored and left out of the record, because nothing this
 simulator models can tell the difference. There is no simulated KMS, Object bytes are stored as they
 arrive, and no simulated service reads a Bucket tag. CDK puts both on almost every Bucket it synthesizes, and
@@ -1918,8 +2259,9 @@ them disabled in favour of policies.
 ## Lifecycle configuration
 
 Sim S3 stores a Bucket's lifecycle rules and acts on them. An `Expiration` rule removes the Objects
-it selects once simulated time passes the boundary, and an `AbortIncompleteMultipartUpload` rule
-discards uploads that were started and left unfinished.
+it selects once simulated time passes the boundary, a `NoncurrentVersionExpiration` rule bounds the
+history a versioned Bucket keeps, and an `AbortIncompleteMultipartUpload` rule discards uploads that
+were started and left unfinished.
 
 Retention is otherwise the one property of a log or a backup Bucket a test cannot demonstrate.
 Reading the rules back off a deployed Bucket says the rules arrived. Putting an Object, moving the
@@ -1985,6 +2327,100 @@ what the rules leave at that instant, and a Bucket carrying no rules costs one c
 the clock backwards afterwards leaves an expired Object gone, because the rule deleted it on the way
 past.
 
+### Bounding the history a versioned Bucket keeps
+
+A versioned Bucket gains a version on every write and keeps every one of them. A
+`NoncurrentVersionExpiration` rule bounds that. `NoncurrentDays` removes a version once simulated
+time passes it, counted from the moment that version stopped being current rather than from its
+write, which is how real S3 measures it. A version written a year ago and displaced yesterday has
+been noncurrent for a day.
+
+```typescript sim-s3-noncurrent-expiry
+/**
+ * Bounding a reader's history at ninety days of noncurrent versions.
+ */
+
+import {
+  ListObjectVersionsCommand,
+  PutBucketLifecycleConfigurationCommand,
+  PutBucketVersioningCommand,
+  PutObjectCommand,
+} from "@aws-sdk/client-s3";
+
+import { SimAws } from "@kensio/yulin";
+
+const simAws = new SimAws();
+const simS3 = simAws.s3();
+
+const stack = await simAws.cloudFormation().deployTemplate({
+  stackName: "history-stack",
+  template: {
+    Resources: {
+      HistoryBucket: {
+        Type: "AWS::S3::Bucket",
+        Properties: { BucketName: "reader-history" },
+      },
+    },
+  },
+});
+await stack.waitForDeployComplete();
+
+await simS3.putBucketVersioning(
+  new PutBucketVersioningCommand({
+    Bucket: "reader-history",
+    VersioningConfiguration: { Status: "Enabled" },
+  }),
+);
+
+await simS3.putBucketLifecycleConfiguration(
+  new PutBucketLifecycleConfigurationCommand({
+    Bucket: "reader-history",
+    LifecycleConfiguration: {
+      Rules: [
+        {
+          ID: "bound-history",
+          Status: "Enabled",
+          Filter: { Prefix: "snapshots/" },
+          NoncurrentVersionExpiration: { NoncurrentDays: 90 },
+        },
+      ],
+    },
+  }),
+);
+
+const snapshot = {
+  Bucket: "reader-history",
+  Key: "snapshots/reader-1.json",
+};
+
+await simS3.putObject(new PutObjectCommand({ ...snapshot, Body: "before" }));
+await simS3.putObject(new PutObjectCommand({ ...snapshot, Body: "after" }));
+
+await simAws.clock().advanceBy({ days: 91 });
+
+const listed = await simS3.listObjectVersions(
+  new ListObjectVersionsCommand({ Bucket: "reader-history" }),
+);
+
+// The version the second write displaced has gone, and the current one stays
+// however old it is.
+console.log(listed.Versions?.length); // 1
+```
+
+`NewerNoncurrentVersions` holds that many of the most recent noncurrent versions back from the rule,
+whatever their age, so a rule keeping two reaches the third and everything older. Real S3 requires
+`NoncurrentDays` alongside it, and a rule stating the count on its own names no period to measure and
+expires nothing.
+
+`ExpiredObjectDeleteMarker` under `Expiration` removes a delete marker left with no version under it,
+which takes the key out of `ListObjectVersions` altogether. A marker still hiding a version stays,
+since that marker is what a read of the key answers with. The two run in that order in one pass, so a
+marker whose last version expired in the same pass goes with it.
+
+A noncurrent version is removed from the Bucket's history, and a `GetObject` naming its `VersionId`
+answers `NoSuchVersion` afterwards. The current version is beyond every rule of this kind, however
+old it is.
+
 ### What a rule selects
 
 A rule selects Objects by its `Filter`, or by the older top-level `Prefix`. A rule with no scope at
@@ -2075,14 +2511,17 @@ all three, and a rule stored here that real S3 would have rejected reads back lo
 CloudFormation spells some rule fields differently from the request. `Id` becomes `ID`,
 `ExpirationInDays` and `ExpirationDate` are gathered under `Expiration`, and a transition's
 `TransitionInDays` becomes `Days`. The singular `Transition` a template may state alongside
-`Transitions` joins the list. Everything else, `Status`, `Prefix`, `AbortIncompleteMultipartUpload`,
-`TagFilters` and the object size bounds among them, is carried across as the template stated it.
+`Transitions` joins the list. `NoncurrentVersionExpirationInDays` becomes the `NoncurrentDays` of a
+`NoncurrentVersionExpiration`, which is what CDK's `noncurrentVersionExpiration` synthesises, and a
+template stating the nested object instead is taken as it stands. Everything else, `Status`,
+`Prefix`, `AbortIncompleteMultipartUpload`, `TagFilters` and the object size bounds among them, is
+carried across as the template stated it.
 
 `LifecycleConfiguration` is one of the properties simulated S3 acts on. It stays out of
 [`stack.ignoredProperties`](https://yulinsim.dev/services/cloudformation/#properties-a-resource-was-created-without).
-The two actions it enforces are `Expiration`, whether the template flattened it onto the rule or
-not, and `AbortIncompleteMultipartUpload`. A `Transitions` rule is stored and read back and goes no
-further. Which Objects an enforced action reaches is decided by the fields listed under
+The three actions it enforces are `Expiration`, whether the template flattened it onto the rule or
+not, `NoncurrentVersionExpiration`, in either of its two spellings, and
+`AbortIncompleteMultipartUpload`. A `Transitions` rule is stored and read back and goes no further. Which Objects an enforced action reaches is decided by the fields listed under
 [What a rule selects](#what-a-rule-selects).
 
 ### Limitations
@@ -2093,8 +2532,11 @@ No Object moves between storage classes. Storage classes are left out of the sim
 Real S3 raises `s3:LifecycleExpiration:Delete` when a rule removes an Object. That event family is
 among the ones sim S3 leaves out. An expiry here is silent.
 
-`NoncurrentVersionExpiration`, `NoncurrentVersionTransitions` and `ExpiredObjectDeleteMarker` are
-stored and unread, because Object versions are left out.
+`NoncurrentVersionTransitions` is stored and unread, alongside `Transitions`, because storage classes
+are left out. An `Expiration` rule on a versioned Bucket writes a delete marker over the current
+version and leaves the version itself where it is, which is what real S3 does, and a
+`NoncurrentVersionExpiration` rule is what then removes it. See
+[Object versioning](#object-versioning).
 
 A Bucket mounted on a filesystem directory refuses the deletion an expiry asks for, the way it
 refuses `DeleteObject`, and answers `NotImplemented`. Removing a real file off the mounted directory
@@ -2980,6 +3422,9 @@ Sim S3 currently supports:
 - `PutBucketNotificationConfigurationCommand` and `GetBucketNotificationConfigurationCommand`, with
   Object events delivered to a simulated Lambda function, a simulated SQS queue or a simulated SNS
   topic
+- `PutBucketVersioningCommand`, `GetBucketVersioningCommand` and `ListObjectVersionsCommand`, with
+  every write of a key kept, a delete writing a marker over it, and a named version readable and
+  removable on its own
 - `PutBucketWebsiteCommand`, for static website hosting
 - `PutBucketLifecycleConfigurationCommand`, `GetBucketLifecycleConfigurationCommand` and
   `DeleteBucketLifecycleCommand`, storing a Bucket's lifecycle rules and handing them back without
@@ -3012,8 +3457,6 @@ needs them to model the requested behaviour.
 
 These apply across the page. The sections above each list what is specific to them.
 
-- Object versioning is left out. There are no version ids, no delete markers and no `VersionId` on
-  any request or response.
 - A listing reports `StorageClass` as `STANDARD` for every Object. Storage classes themselves are
   left out, and every Object is in that one.
 - `EncodingType` is ignored on a listing, and keys come back unencoded.

package/docs/services/scheduler/README.md

@@ -238,6 +238,39 @@ console.log(failure?.message);
 `JSON.stringify` on a failure carries the message alongside the schedule, the target, the role and
 the instant it names.
 
+A Lambda target has another boundary. Scheduler records a failure when it cannot assume the role,
+the role cannot invoke the function, the function is missing or Lambda refuses the request. Once
+Lambda accepts the asynchronous invocation, its event invoke config applies. Handler errors follow
+Lambda's retry, destination and function dead-letter queue settings and do not appear in
+`deliveryFailures`.
+
+### Retrying and dead-lettering a delivery
+
+Set `Target.RetryPolicy` to retry a failure that may clear. `MaximumRetryAttempts` is the number of
+attempts after the first one and accepts 0 through 185. `MaximumEventAgeInSeconds` accepts 60 through
+86,400. If the policy leaves either member out, its effective value is 185 attempts or 86,400
+seconds. `GetSchedule` still reports the policy as it was written.
+
+Retries use the simulation's clock. The first retry is due one second after the failed attempt. Each
+following delay doubles to 2, 4, 8 seconds and so on. A retry does not run while the clock stands
+still. `advanceBy(...)` runs every retry that becomes due in the interval and settles their work
+before it returns.
+
+Scheduler does not retry a failure that cannot clear by trying the same request. A missing target,
+a missing execution role, an execution role that does not trust Scheduler and an IAM denial are
+permanent failures. They are abandoned after the initial attempt.
+
+Set `Target.DeadLetterConfig.Arn` to a standard SQS queue ARN to keep an input that Scheduler abandons.
+The execution role needs `sqs:SendMessage` on this queue as well as permission to invoke the target.
+The message body is the target's original `Input`. Its string message attributes follow Scheduler's
+shape and include the error, schedule ARN, target ARN, scheduled time and retry count.
+`EXHAUSTED_RETRY_CONDITION` is `MaximumRetryAttempts` or `MaximumEventAgeInSeconds` for an exhausted
+retryable failure. A permanent failure leaves that attribute out.
+
+A successful DLQ send does not add an entry to `deliveryFailures`, since the configured destination
+received the input. A missing queue or denied `sqs:SendMessage` is recorded there instead. This keeps
+a misconfigured DLQ visible to a test.
+
 ### One-time schedules and what happens after
 
 An `at(...)` schedule fires once and then stops. By default it stays in the Account afterwards, which
@@ -759,10 +792,12 @@ Resources of the same stack.
 - `at(...)`, `rate(...)` and six-field `cron(...)` expressions, fired by advancing the simulation's
   clock.
 - Lambda, SQS and SNS targets, with a target `Input`, invoked as the target's execution role and
-  authorized against that role's own policies.
+  authorized against that role's own policies. Lambda targets use asynchronous Event invocation.
 - ECS targets, running a simulated task as the execution role, with the task definition and
   `TaskCount` from `EcsParameters` and container overrides from the target's `Input`.
 - `ActionAfterCompletion`, and `deliveryFailures` for invocations that did not happen.
+- Target retry policies driven by simulated time, and standard SQS dead-letter queues carrying the
+  original input and Scheduler diagnostic attributes.
 - `CreateScheduleGroup`, `GetScheduleGroup`, `DeleteScheduleGroup` and `ListScheduleGroups`, over
   the `default` group every account and region starts with and any group created beside it.
 - `AWS::Scheduler::Schedule` and `AWS::Scheduler::ScheduleGroup` deployed from a CloudFormation
@@ -779,9 +814,12 @@ Resources of the same stack.
   of it, and a simulation left alone in real time never fires however long it is left.
 - Firing is exact and exactly once. Real Scheduler invokes within a minute of the due time, and its
   promise is at-least-once.
-- An invocation is attempted once. There is no retry and no dead letter queue. A target that throws
-  is recorded as a failure, and never redelivered. A failed invocation never rejects
-  `advanceBy(...)`, and is read from `deliveryFailures`.
+- Retry delays are deterministic powers of two seconds. Real Scheduler uses exponential backoff
+  without publishing an exact sequence. The fixed sequence lets a test advance to a known retry
+  instant.
+- Delivery retries cover failures before the target accepts the request. A Lambda handler failure
+  happens after Lambda accepts its asynchronous invocation and uses Lambda's retry, destination and
+  function dead-letter queue settings instead.
 - A schedule group carries no tags. `CreateScheduleGroup` refuses `Tags`, since the simulation
   stores them nowhere. A template's `Tags` are recorded as an ignored property and the group still
   deploys.
@@ -798,9 +836,10 @@ Resources of the same stack.
 - Targets are Lambda, SQS, SNS and ECS. The universal target
   (`arn:aws:scheduler:::aws-sdk:<service>:<action>`) and every other target service are refused when
   the schedule is created, ahead of the first due instant.
-- A target `DeadLetterConfig`, `RetryPolicy`, `EventBridgeParameters`, `KinesisParameters`,
-  `SageMakerPipelineParameters` and `SqsParameters` are refused outright, as is `EcsParameters` on a
-  target whose ARN names something other than an ECS cluster.
+- A target `EventBridgeParameters`, `KinesisParameters`, `SageMakerPipelineParameters` and
+  `SqsParameters` are refused outright, as is `EcsParameters` on a target whose ARN names something
+  other than an ECS cluster. A `DeadLetterConfig` must name a standard SQS queue because simulated
+  SQS does not support FIFO queues.
 - An ECS target's `EcsParameters` takes `TaskDefinitionArn` and `TaskCount`, and takes and ignores
   `LaunchType`, `PlatformVersion`, `NetworkConfiguration` and `CapacityProviderStrategy`, since
   there is no placement and no network here for them to apply to. Anything else it can carry, such
@@ -810,5 +849,5 @@ Resources of the same stack.
   on an ECS target, where every other target type takes any text.
 - A `TaskCount` above one runs that many simulated tasks, and a bound container handler runs once
   for each of them, in this process and one after another.
-- `KmsKeyArn` is refused, and `ClientToken` is accepted and ignored. Nothing here retries, so it has
-  no request to make idempotent.
+- `KmsKeyArn` is refused, and `ClientToken` is accepted and ignored. Schedule management requests
+  are not retried, so the token has no request to make idempotent.