@kensio/yulin 1.21.7 → 1.21.9

package/docs/services/kms/README.md

@@ -1,17 +1,15 @@
 # Simulated KMS
 
-Yulin includes a simulated AWS Key Management Service (KMS) for tests and local development.
-
-Encryption is real. Each simulated key holds AES-256 key material and the operations run through
-Node.js's own `crypto`. A ciphertext can only be read with its key, and a decryption with the wrong
-encryption context fails.
+Yulin simulates AWS Key Management Service (KMS) in memory. Symmetric keys use AES-256 key material,
+and asymmetric keys use real key pairs. Cryptographic operations run through Node.js `crypto`, so
+the wrong key or encryption context cannot decrypt a ciphertext.
 
 KMS-specific types are imported from the `@kensio/yulin/kms` subpath.
 
 ## Encrypting and decrypting
 
-Create a key and use it. `Decrypt` needs no `KeyId` for a symmetric key, because the ciphertext
-already names the key that produced it.
+Create a key, encrypt a value, then decrypt it. `Decrypt` does not need a `KeyId` for symmetric
+ciphertext because the ciphertext identifies its key.
 
 ```typescript sim-kms-encrypt-decrypt
 /**
@@ -52,8 +50,8 @@ any second `SimAws` instance both reject it.
 
 ## Encryption context
 
-An encryption context is non-secret key/value data bound to a ciphertext. Decryption with a
-different context fails. That ties a ciphertext to the thing it belongs to.
+An encryption context binds non-secret key/value data to a ciphertext. Decryption requires the same
+context.
 
 ```typescript sim-kms-encryption-context
 /**
@@ -100,9 +98,8 @@ The context is an unordered map. The same pairs written in a different order sti
 
 ## Envelope encryption
 
-`Encrypt` takes at most 4096 bytes. That limit is what makes envelope encryption necessary.
-`GenerateDataKey` returns a data key twice, once in the clear to encrypt your data with, and once
-encrypted under the KMS key to store alongside it.
+`Encrypt` accepts at most 4,096 bytes. For larger values, use `GenerateDataKey`. It returns a
+plaintext data key for encryption and an encrypted copy to store with the data.
 
 ```typescript sim-kms-generate-data-key
 /**
@@ -141,8 +138,8 @@ console.log(recovered.Plaintext?.length); // 32
 
 ## Signing and verifying
 
-A key created with `KeyUsage: SIGN_VERIFY` holds a real key pair, and the signatures are real
-signatures. A key spec is required, because the default `SYMMETRIC_DEFAULT` spec cannot sign.
+A key with `KeyUsage: SIGN_VERIFY` holds a real key pair. Set a signing key spec because the default
+`SYMMETRIC_DEFAULT` key cannot sign.
 
 ```typescript sim-kms-sign-verify
 /**
@@ -261,9 +258,8 @@ both matching what KMS produces. `GetPublicKey` against a symmetric key is
 
 ## Key policies and IAM
 
-Every KMS key has a policy, and it cannot be removed. An IAM policy granting `kms:Decrypt` only
-takes effect where the key's own policy admits the caller. How it admits them decides what else is
-needed:
+Every key has a key policy. An identity policy granting `kms:Decrypt` works only when the key policy
+also permits the caller:
 
 - A statement naming the caller grants access outright. A role with no permissions of its own can
   still use the key.
@@ -342,16 +338,15 @@ on real KMS.
 
 ## AWS managed keys and `kms:ViaService`
 
-An alias beginning `alias/aws/` names an AWS managed key, and the key is created the first time
-something references it. Such a key gets the policy real AWS gives it, which differs from the
-customer default:
+An alias beginning with `alias/aws/` names an AWS managed key. Yulin creates that key when it is
+first referenced and applies AWS-managed-key policy behavior:
 
 - Use of the key is allowed to any principal in the owning account, but only when `kms:ViaService`
   names the service that owns the key, such as `ssm.us-east-1.amazonaws.com` for `aws/ssm`.
-- The account root is allowed to read the key's metadata. That is the whole of what this policy
-  delegates to IAM.
+- The account root can read the key's metadata.
 
-That is why a role holding `kms:Decrypt` on such a key cannot use it by calling KMS itself.
+A role cannot use an AWS managed key by calling KMS directly, even when its identity policy grants
+`kms:Decrypt`.
 
 `kms:ViaService` is set by the service making the call on the caller's behalf. Sim SSM does this for
 `SecureString` parameters. Code calling simulated KMS directly sets it with the `viaService` request
@@ -417,8 +412,7 @@ and a condition on it stays unmatched.
 
 ## Naming a key
 
-Every operation takes its target as a `KeyId`, in any of the four forms real KMS accepts. Those are
-a key ID, a key ARN, an alias name such as `alias/app-key`, and an alias ARN.
+`KeyId` accepts a key ID, key ARN, alias name such as `alias/app-key`, or alias ARN.
 
 A key ARN or alias ARN naming another account or region resolves to no key at all. Its identifier is
 never read out and looked up locally. A foreign ARN cannot reach a key that happens to share an
@@ -473,8 +467,8 @@ console.log(managed.KeyMetadata?.KeyManager); // "AWS"
 
 A key can be disabled and re-enabled later. A disabled key stays present, and refuses to be used.
 
-Deletion is never immediate. `ScheduleKeyDeletion` sets a recovery window of 7 to 30 days, defaulting
-to 30. During that window the key refuses to be used but can still be recovered with
+`ScheduleKeyDeletion` sets a recovery window from 7 to 30 days, defaulting to 30. During that window
+the key cannot be used but can be recovered with
 `CancelKeyDeletion`. Cancelling leaves the key disabled. Re-enabling it is a separate step.
 
 A disabled key fails cryptographic operations with `DisabledException`. A key pending deletion fails
@@ -600,9 +594,7 @@ the function's execution role as the caller. A handler that decrypts a value the
 allowed to, by both the key policy and the role's identity policy, the same as on real AWS. See
 [simulated Lambda](https://yulinsim.dev/services/lambda/) for how function code and execution roles work.
 
-## Available functionality
-
-Sim KMS currently supports:
+## Supported operations
 
 - `CreateKeyCommand`, for symmetric encryption keys and asymmetric signing keys
 - `DescribeKeyCommand` and `ListKeysCommand`
@@ -619,8 +611,6 @@ Sim KMS currently supports:
 
 ## Limitations
 
-Current documented limitations:
-
 - Only encryption with a symmetric key and signing with an asymmetric key are simulated. Left out
   are asymmetric encryption (`RSAES_OAEP_SHA_1` and `RSAES_OAEP_SHA_256`), HMAC keys and
   `GENERATE_VERIFY_MAC`, key agreement and `DeriveSharedSecret`, the `SM2` key spec, and

package/docs/services/lambda/README.md

@@ -1,7 +1,7 @@
 # Simulated Lambda
 
-Yulin includes a simulated AWS Lambda service for tests and local development. Functions are created
-and invoked in-process and in memory, with no containers and no real AWS infrastructure.
+Yulin creates and invokes Lambda functions in process. A function can use an in-process handler,
+code from a zip archive, code stored in simulated S3, or a handler bound to a container image.
 
 Handlers run with their execution role as the simulated caller, so AWS calls made inside a handler
 are authorized by simulated IAM, as on real Lambda. Creating a function and changing its role are
@@ -9,16 +9,14 @@ authorized as well, both against `lambda:` actions and against `iam:PassRole` on
 the request names. See [passing a Role to a service](https://yulinsim.dev/services/iam/#passing-a-role-to-a-service)
 in the IAM docs.
 
-Lambda-specific helpers are imported from the `@kensio/yulin/lambda` subpath. Real `LambdaClient`
-instances can be routed into sim Lambda with
+Lambda helpers are available from `@kensio/yulin/lambda`. A `LambdaClient` can be routed to Yulin with
 [SDK interception](https://yulinsim.dev/sdk/ "Simulated AWS SDK interception docs").
 
 ## Creating and invoking a function
 
-The quickest way to a working function is to pass a real in-process handler function through the
-SDK-shaped `Code.ZipFile` input with `makeLambdaZipFileInput(...)`. The handler is an ordinary
-function in your Node.js process. It can be stepped through in a debugger and can close over local
-state.
+Use `makeLambdaZipFileInput(...)` to pass an in-process handler through the SDK-shaped `Code.ZipFile`
+input. The handler runs as an ordinary function in the Node.js process. It supports breakpoints and
+access to local state.
 
 ```typescript sim-lambda-create-and-invoke
 /**
@@ -84,18 +82,13 @@ The invoke call itself returns normally.
 
 ## Zip-packaged code and the vm runtime
 
-A real in-process handler is the one to reach for first. `makeLambdaZipFileInput(...)` backs a
-function created through the SDK with one, and an [executable binding](#executable-bindings) backs
-one a template declares. The handler stops on a breakpoint and can close over the test's own state.
-Run the packaged code where the test is about the bundle a deployment ships, its imports and its
-bundling included. Both paths invoke through simulated Lambda, and simulated IAM authorizes the
-handler's own AWS calls under the execution role either way.
+Use an in-process handler for most tests. Use packaged code when the test covers the deployed bundle,
+including its imports. Both forms run through simulated Lambda and make AWS calls as the function's
+execution role.
 
-Real Lambda receives function code as a zip archive. `makeLambdaCodeZip(...)` builds real zip
-bytes from a source string (which becomes a single `index.js` module) or from a files map keyed by
-archive path (like a bundled deployment package). The archive runs in a Node.js `vm` context with
-real cold-start semantics. The module is imported once, on first invocation, and module state stays
-warm across invocations.
+`makeLambdaCodeZip(...)` builds zip bytes from a source string or a map of archive paths to file
+contents. A source string becomes `index.js`. Yulin runs the archive in a Node.js `vm`, loads the
+module on the first invocation and preserves module state for later invocations.
 
 ```typescript sim-lambda-zip-code-vm-runtime
 /**
@@ -171,18 +164,15 @@ package is refused at cold start. A handler file ending in `.mjs` is reported as
 Real Lambda has run ES module packages since nodejs14.x, and `NodejsFunction` in CDK emits one
 under `format: OutputFormat.ESM`.
 
-There are two ways round that. An [executable binding](#executable-bindings) or
-`makeLambdaZipFileInput(...)` backs the function with a real in-process handler. The test's own
-module system loads that handler, and its format is whatever the test file's is. An ESM project
-needs nothing further. Where the archive itself has to be the deployed artefact, compile a CommonJS
-build of the same source and deploy that as the function's code.
+Use an [executable binding](#executable-bindings) or `makeLambdaZipFileInput(...)` for an ESM handler.
+The test's module system loads an in-process handler. To test the archive itself, compile the source
+to CommonJS before creating the zip.
 
 `Code.ZipFile` bytes that fail to unzip are rejected at creation with the AWS-like
 `InvalidParameterValueException: Could not unzip uploaded file`.
 
-The archives are real zip files, and they interoperate with real tooling in both directions. A zip
-built by any other tool works as `Code.ZipFile` input, and `makeLambdaCodeZip` output can be
-unzipped normally.
+`Code.ZipFile` accepts zip archives produced by other tools. Archives from `makeLambdaCodeZip` can
+also be opened with standard zip tools.
 
 ### What a handler prints
 
@@ -408,9 +398,8 @@ writes none of those.
 
 ## Function code from S3
 
-Function code can also be fetched from a zip object stored in sim S3, as SAM and CDK deployments
-do on real AWS. The code object is fetched once at creation time, as the creating caller, so
-simulated IAM applies to the code object read.
+Function code may reference a zip object in simulated S3. Yulin reads the object once during
+function creation as the caller creating the function, so simulated IAM applies to the S3 read.
 
 ```typescript sim-lambda-s3-code
 /**
@@ -944,10 +933,9 @@ the operation header that says so.
 
 ## Invocation types
 
-`InvokeCommand` supports the three AWS invocation types. `RequestResponse` (the default) awaits
-the handler and returns its JSON-serialised result as the response payload. `Event` returns `202`
-immediately and runs the handler in the background. `DryRun` returns `204` without invoking the
-handler at all.
+`InvokeCommand` supports all three invocation types. `RequestResponse` waits for the handler and
+returns its JSON result. `Event` returns 202 and schedules the handler in the background. `DryRun`
+returns 204 without invoking the handler.
 
 ```typescript sim-lambda-invocation-types
 /**
@@ -1007,14 +995,12 @@ covers.
 
 ## Asynchronous retries and destinations
 
-An `Event` invocation whose handler throws is retried twice, as real Lambda retries one. The retries
-wait on the simulated clock, about a minute before the first and two before the second, so a test
-reaches them by advancing time rather than by waiting for it.
+An `Event` invocation retries a failed handler twice by default. Retries use the simulated clock,
+after about one minute and then two minutes. Advance the clock to run them in a test.
 
-`PutFunctionEventInvokeConfigCommand` changes how many retries a function makes and where its
-results go. An invocation that fails its last attempt is sent to the `OnFailure` destination, and
-one whose handler returns is sent to `OnSuccess`. A destination ARN can name a simulated SQS queue,
-SNS topic, EventBridge event bus or Lambda function.
+`PutFunctionEventInvokeConfigCommand` controls retry count and destinations. Lambda sends a final
+failure to `OnFailure` and a successful result to `OnSuccess`. Destinations may be SQS, SNS,
+EventBridge or another Lambda function.
 
 The source function's execution role must allow the operation that writes to the destination:
 
@@ -1154,11 +1140,9 @@ a config of its own, and an invocation of a qualifier with no config of its own
 
 ### Dead-letter targets
 
-`DeadLetterConfig` is the older way to keep a failed asynchronous invocation, and simulated Lambda
-takes it on `CreateFunction` and `UpdateFunctionConfiguration`. Its `TargetArn` names a simulated
-SQS queue or SNS topic, which receives the event as it was invoked rather than the destination
-record around it. The execution role needs `sqs:SendMessage` for a queue or `sns:Publish` for a
-topic. A denied delivery rejects the background task and leaves the target unchanged.
+`DeadLetterConfig` sends a failed asynchronous event to SQS or SNS. Configure it with
+`CreateFunction` or `UpdateFunctionConfiguration`. The target receives the original event rather
+than a destination record. The execution role needs `sqs:SendMessage` or `sns:Publish`.
 
 ```typescript sim-lambda-dead-letter-queue
 /**
@@ -1249,11 +1233,9 @@ A function carrying both a dead-letter target and an `OnFailure` destination sen
 
 ## Versions and aliases
 
-`PublishVersionCommand` copies a function as it stands and numbers the copy. The first is version
-`1`, and each later one counts up. The copy keeps the code, handler, timeout, memory and
-environment it was published with. `CreateAliasCommand` gives one of those versions a name, and
-`UpdateAliasCommand` moves the name to another version, so a deployment can repoint what callers
-invoke.
+`PublishVersionCommand` creates an immutable numbered copy of the function's code and configuration.
+Versions start at `1`. `CreateAliasCommand` gives a version a name, and `UpdateAliasCommand` moves
+that name to another version.
 
 `InvokeCommand` and `GetFunctionCommand` take a `Qualifier` naming a version number or an alias.
 The same qualifier can travel on the `FunctionName` instead, appended to the name (`orders:live`)
@@ -1366,9 +1348,8 @@ ARN. A `FunctionName` carrying a qualifier (`orders:live`) is refused with an
 
 ## Triggering a function from an SQS queue
 
-An event source mapping connects a [simulated queue](https://yulinsim.dev/services/sqs/ "Simulated SQS docs") to a function.
-Messages sent to the queue are delivered to the handler as an SQS event, with the `Records` shape
-real Lambda uses.
+An event source mapping polls a [simulated queue](https://yulinsim.dev/services/sqs/ "Simulated SQS docs") and invokes the function
+with an SQS `Records` event.
 
 Polling runs on the simulation's background scheduler. A test awaits
 `simAws.backgroundTasksComplete()` and then asserts, without sleeping.
@@ -1600,10 +1581,9 @@ from.
 
 ### When the handler fails
 
-A handler that returns normally has handled the batch, and the messages are deleted from the queue.
-A handler that throws returns the whole batch. The messages stay on the queue, hidden until their
-visibility timeout lapses, and are delivered again after that. Advancing the simulation's clock is
-what brings them back:
+A successful handler deletes the batch from the queue. When the handler throws, every message stays
+in flight until its visibility timeout expires, then becomes available for another delivery. Advance
+the simulated clock to reach that retry:
 
 ```typescript
 await simAws.clock().advanceBy({ seconds: 31 });
@@ -1618,10 +1598,8 @@ the sender sees is the message coming back.
 
 ### Reporting individual message failures
 
-A queue mapping created with `FunctionResponseTypes: ["ReportBatchItemFailures"]` takes the
-`batchItemFailures` list the handler returns. The message ids named in it go back to the queue, and
-the rest of the batch is deleted. A stream mapping takes the same list and does something else with
-it, under [reporting individual record failures](#reporting-individual-record-failures).
+A queue mapping with `FunctionResponseTypes: ["ReportBatchItemFailures"]` reads the handler's
+`batchItemFailures`. Named message IDs return to the queue and the remaining messages are deleted.
 
 ```typescript
 await simAws.lambda().createEventSourceMapping(
@@ -1646,9 +1624,8 @@ or an empty `batchItemFailures` list, has handled the whole batch.
 
 ### Making an SQS event without a queue
 
-A test of the handler on its own, with no queue and no mapping, still has to pass it a whole event.
-`lambdaSqsEventFactory` makes one, and `lambdaSqsEventRecordFactory` makes the records in it. Such a
-test then says what the messages carry and leaves the rest to the factory:
+Use `lambdaSqsEventFactory` and `lambdaSqsEventRecordFactory` to call an SQS handler without creating
+a queue or event source mapping:
 
 ```typescript sim-lambda-sqs-event-factory
 /**
@@ -1708,9 +1685,9 @@ the same records whether it carries them or not. The deploy stands and nothing r
 
 ## Triggering a function from a DynamoDB stream
 
-An event source mapping also connects a [simulated table's stream](https://yulinsim.dev/services/dynamodb/#capturing-changes-with-a-stream "Simulated DynamoDB streams docs")
-to a function. Changes to the table are delivered to the handler as a DynamoDB stream event, with
-the `Records` shape real Lambda uses.
+An event source mapping can also poll a
+[simulated DynamoDB stream](https://yulinsim.dev/services/dynamodb/#capturing-changes-with-a-stream "Simulated DynamoDB streams docs").
+Table changes reach the handler as a DynamoDB `Records` event.
 
 `StartingPosition` is required for a stream and is `TRIM_HORIZON` or `LATEST`. `TRIM_HORIZON` reads
 what the stream still holds, so changes made before the mapping existed are delivered too. `LATEST`
@@ -1927,7 +1904,7 @@ with more steps.
 `MaximumRetryAttempts` and `MaximumRecordAgeInSeconds` govern the same failed-batch lifecycle, and a
 stream mapping keeps both. `MaximumRetryAttempts: 0` makes one delivery and no retries, and a
 positive value allows that many retries after the first delivery. `MaximumRecordAgeInSeconds`
-discards a record once the next attempt would fall past that age. Lambda's `-1` means no limit
+discards expired records before each invocation, including the first poll. Lambda's `-1` means no limit
 (that is what a mapping naming neither reports back).
 
 ```typescript sim-lambda-stream-retry-limits
@@ -2056,11 +2033,62 @@ discarded, and the mapping reads on from behind it.
 10,000 retries, `-1` to 604,800 seconds) is a `ValidationException`. A queue mapping takes neither,
 because a message the handler never takes is left to the queue's own redrive policy.
 
+### Sending discarded stream batches to a destination
+
+DynamoDB Streams and Kinesis mappings accept `DestinationConfig.OnFailure` with a standard SQS
+queue or SNS topic ARN. Supply it to `CreateEventSourceMapping` or the
+`AWS::Lambda::EventSourceMapping` resource alongside the retry and record-age limits:
+
+```json
+{
+  "MaximumRetryAttempts": 10,
+  "MaximumRecordAgeInSeconds": 3600,
+  "DestinationConfig": {
+    "OnFailure": {
+      "Destination": "arn:aws:sqs:eu-west-2:111111111111:stream-failures"
+    }
+  }
+}
+```
+
+CDK's `DynamoEventSource` and `KinesisEventSource` accept `onFailure: new SqsDlq(queue)` or
+`onFailure: new SnsDlq(topic)`. Their synthesized destination configuration is passed through to
+the simulated mapping. Create, Get, List and Delete responses preserve that configuration.
+
+The function's execution role needs `sqs:SendMessage` on the queue or `sns:Publish` on the topic.
+Delivery goes through the simulated destination service, so its IAM checks and SNS subscriptions
+apply. An IAM denial or a missing destination rejects `backgroundTasksComplete()` or the clock
+advance that exhausted the batch. The discarded records have already advanced the checkpoint.
+Yulin attempts destination delivery once and does not retry a failed send.
+
+The JSON message follows the AWS
+[DynamoDB Streams](https://docs.aws.amazon.com/lambda/latest/dg/services-dynamodb-errors.html) and
+[Kinesis](https://docs.aws.amazon.com/lambda/latest/dg/kinesis-on-failure-destination.html)
+notification formats. Import `SimLambdaStreamFailureRecord` from `@kensio/yulin/lambda` to type it.
+
+- `version` is `"1.0"` and `timestamp` is the simulated discard time in ISO 8601 format.
+- `requestContext` contains a generated `requestId`, the mapping's `functionArn`,
+  `approximateInvokeCount`, and either `RetryAttemptsExhausted` or `RecordAgeExceeded` as `condition`.
+- `responseContext` reports `statusCode: 200` and `executedVersion`. A handler error adds
+  `functionError: "Unhandled"`. A valid partial-batch failure response leaves that field out.
+  Records discarded before any invocation omit `responseContext`.
+- `DDBStreamBatchInfo` or `KinesisBatchInfo` identifies the stream ARN, shard ID, first and last
+  sequence numbers, first and last arrival times, and batch size. Arrival times are ISO 8601 strings.
+
+The original record payloads are absent. A successful batch produces no notification. After a
+partial-batch response, the notification covers the discarded suffix starting at the failed
+checkpoint. When only an older prefix expires, its notification excludes the younger records.
+Records already expired on their first poll report zero invocations. Request IDs are generated for
+the notification and are not correlated with the handler's invocation context.
+
+S3 destinations, FIFO queues or topics, and `OnSuccess` are refused. SQS source mappings cannot
+have this destination configuration. The simulator's existing five-retry cap for mappings with
+neither limit also produces a failure notification when it discards a batch.
+
 ### Reporting individual record failures
 
-A stream mapping created with `FunctionResponseTypes: ["ReportBatchItemFailures"]` takes the
-`batchItemFailures` list the handler returns. For a stream the identifier is the record's
-`SequenceNumber`:
+A stream mapping with `FunctionResponseTypes: ["ReportBatchItemFailures"]` reads the handler's
+`batchItemFailures`. Each item identifies a record by `SequenceNumber`:
 
 ```typescript
 await simAws.lambda().createEventSourceMapping(
@@ -2297,8 +2325,7 @@ the three stream actions on the stream ARN and `dynamodb:ListStreams` on every s
 the mapping's execution-role check is looking for.
 
 The properties a non-default `DynamoEventSource` adds are refused by name. Those are
-`FilterCriteria`, `ParallelizationFactor`, `BisectBatchOnFunctionError`, `TumblingWindowInSeconds`
-and `DestinationConfig`.
+`FilterCriteria`, `ParallelizationFactor`, `BisectBatchOnFunctionError` and `TumblingWindowInSeconds`.
 
 A hand-written template or a SAM application usually gives the function the AWS managed policy
 `AWSLambdaDynamoDBExecutionRole` instead. Simulated IAM has no model for managed policy ARNs, so
@@ -2308,15 +2335,13 @@ Write the grant as an inline policy, as the example above and CDK both do.
 
 ## Triggering a function from a Kinesis stream
 
-An event source mapping also connects a [simulated Kinesis stream](https://yulinsim.dev/services/kinesis/ "Simulated Kinesis Data Streams docs")
-to a function. Records put onto the stream are delivered to the handler as a Kinesis event, with the
-`Records` shape real Lambda uses.
+An event source mapping can poll a
+[simulated Kinesis stream](https://yulinsim.dev/services/kinesis/ "Simulated Kinesis Data Streams docs") and invoke the function
+with a Kinesis `Records` event.
 
-A Kinesis stream has as many shards as it was created with, and every one of them is read. Real
-Lambda runs a processor per shard, and so does this: each shard keeps its own place on the stream,
-delivers its own batches and backs off on its own when a batch fails. One invocation is given
-records from one shard, so a handler that has to see records in order should put them under one
-partition key, which is what puts them on one shard.
+Yulin reads every shard in a Kinesis stream. Each shard tracks its own iterator, delivers its own
+batches and backs off independently after a failure. An invocation receives records from one shard.
+Use one partition key when the handler requires ordered records.
 
 `StartingPosition` is required for a stream. A Kinesis stream takes all three positions.
 `TRIM_HORIZON` reads what the stream still holds, `LATEST` reads only what arrives from the moment
@@ -4180,8 +4205,10 @@ Current documented limitations:
 - Throttling does not drive a retry. A retry follows a handler that threw or ran out of time, and
   the `MaximumEventAgeInSeconds` a config carries is measured from when the invocation was
   accepted.
-- `DestinationConfig` on an event source mapping is left out. It is a different mechanism from the
-  asynchronous invocation destinations above.
+- Stream mappings support standard SQS and SNS `DestinationConfig.OnFailure` destinations.
+  S3 destinations and `OnSuccess` are refused. Destination delivery is attempted once. A delivery
+  failure rejects the background task after the discarded records have advanced the checkpoint.
+  Destination delivery retries and `DestinationDeliveryFailures` metrics are not simulated.
 - A settings change takes effect at once. Real Lambda reports `LastUpdateStatus: "InProgress"` while
   it rolls the change out, and neither that member nor the wait it implies is simulated.
 - A cross-account grant is only half of what admits a call. The caller's own Account has to allow
@@ -4271,7 +4298,7 @@ Current documented limitations:
   it stands.
 - SQS queues, DynamoDB streams and Kinesis streams are the only event sources. Kafka, DocumentDB and
   Kinesis enhanced fan-out consumers are refused outright, and so are `FilterCriteria`,
-  `ScalingConfig`, `DestinationConfig`, `BisectBatchOnFunctionError`, `ParallelizationFactor`,
+  `ScalingConfig`, `BisectBatchOnFunctionError`, `ParallelizationFactor`,
   `TumblingWindowInSeconds` and the other mapping inputs this simulation has no behaviour for. An
   `AWS::Lambda::EventSourceMapping` carrying `Tags` is the exception, and deploys with the tags
   dropped and the property recorded.