ministackorg/ministack v1.4.2

on GitHub

What's Changed

New Contributors

• @ifutivic made their first contribution in #1068

[1.4.2] — 2026-07-13

Added

• IoT — AWS::IoT::TopicRule CloudFormation support — deploying an AWS::IoT::TopicRule previously failed with Unsupported resource type: AWS::IoT::TopicRule and rolled the stack back. A provisioner now creates and deletes the rule (normalizing the PascalCase TopicRulePayload — Sql, Actions, Lambda/FunctionArn, … — to the API's camelCase shape), Ref returns the rule name and Fn::GetAtt Arn the rule ARN. The IoT control plane gains the backing operations: CreateTopicRule, GetTopicRule, ListTopicRules, ReplaceTopicRule, and DeleteTopicRule. Rules are account-scoped and persisted with the rest of the IoT state. Contributed by @maximoosemine.

Changed

• SNS, Kinesis, KMS, and ElastiCache — region-isolated state — continuing the 1.4.0 multi-region work, four more services move their state to account+region scope: SNS (topics, subscriptions, platform applications, platform endpoints), Kinesis (streams, shard iterators — which now also survive a warm boot, still subject to their 5-minute expiry — and enhanced-fan-out consumers), KMS (keys and aliases — the same alias name can now target different keys per region, as on AWS), and ElastiCache (clusters, replication groups, subnet/parameter groups, snapshots, users, user groups, and events; local Redis/Memcached container names now carry the account and region so same-name clusters coexist across regions). Same-name resources in different regions no longer collide, cross-region lookups return the same errors real AWS returns, and background pollers process each resource under its own account and region. Legacy persisted state migrates by recovering each record's region from its stored ARNs; records without an ARN migrate to the default region (MINISTACK_REGION). Contributed by @Areson.

Fixed

• DynamoDB — validation parity with real AWS on reads, deletes, batches, and transactions — validation gaps that let malformed requests succeed silently (all verified against real AWS DynamoDB): (1) GetItem, DeleteItem, and BatchGetItem now reject key attributes carrying an empty string/binary value, as PutItem already did; (2) BatchWriteItem validates every member before applying any — previously a bad member returned the correct ValidationException but earlier members were already written; (3) TransactWriteItems validates every member before applying anything and matches real AWS's two failure shapes: an empty-string/binary key value (or malformed item) is an up-front top-level ValidationException, whereas a wrong-typed key or an update-expression type error is surfaced as a TransactionCanceledException with a positional ValidationError cancellation reason — previously an invalid member was silently committed with no error at all; (4) Query rejects a KeyConditionExpression BETWEEN with inverted bounds at parse time with the AWS error message, instead of returning an empty result; (5) Query validates key-condition operands like key values — an empty string/binary operand on a key attribute is rejected; (6) Query rejects an ExclusiveStartKey whose sort value violates the range-key predicate (The provided starting key does not match the range key predicate) — such a cursor can never have been issued by a previous page; (7) UpdateItem SET rejects a document path that doesn't resolve on the item (The provided expression refers to an attribute that does not exist in the item) — e.g. list_append on a missing attribute, where if_not_exists is the sanctioned form; previously the assignment was silently skipped; (8) UpdateItem ADD/DELETE reject non-Number/Set operands (Incorrect operand type for operator or function, with the AWS quirk that the typeSet is reported as ALLOWED_FOR_ADD_OPERAND even for DELETE) and operands whose type doesn't match the existing attribute (An operand in the update expression has an incorrect data type) — previously ADD could silently replace a set attribute with a number, and DELETE silently no-opped. All error shapes verified against real AWS DynamoDB. Contributed by @ifutivic.
• DynamoDB — Query/Scan return LastEvaluatedKey when results end exactly at Limit — real DynamoDB doesn't look ahead: whenever it stops because of the limit it returns a LastEvaluatedKey, even if nothing remains, and the follow-up page comes back empty with no key. MiniStack only returned the key when strictly more items remained, so SDK pagination helpers that rely on the exact-limit page (e.g. "has more pages" checks) diverged from AWS. Verified against DynamoDB Local. Contributed by @ifutivic.
• Step Functions — aws-sdk:lambda write actions — createFunction, updateFunctionConfiguration, updateFunctionCode, createAlias, and updateAlias now dispatch through the Lambda REST emulator (previously they failed with States.Runtime: not yet implemented; only getAlias and getFunctionConfiguration were covered). The SFN SDK-convention KmsKeyArn parameter is mapped to Lambda's wire-form KMSKeyArn so it's honored instead of silently ignored, task output keys use the same SFN casing convention as the other dispatchers, and Lambda errors surface with prefixed codes so Catch clauses match. Contributed by @Areson.
• API Gateway v2 — WebSocket $connect invokes JWT authorizers — a JWT authorizer configured on the $connect route was ignored, so any client could connect without a token. The route's authorizer is now validated exactly like the HTTP API path — missing or invalid tokens close the connection with code 1008, and validated claims and scopes are injected into requestContext.authorizer.jwt for the integration. Reported by @Lukasdoe.
• S3 — versioned GetObject returns the body after a restart with S3_PERSIST=1 — object-version records live in memory only, so after a restart a GetObject with versionId (for the id restored via the 1.4.1 metadata sidecar) found a version record with no data and returned an empty body. Restore now seeds the current version from the on-disk sidecar, and versioned reads fall back to the persisted object body on disk. Reported by @adzcodemi.
• SQS — XML error responses carry the legacy query-protocol error codes — the query-protocol (XML) error path emitted the modern JSON-protocol code in <Code> (e.g. QueueDoesNotExist), but SDKs speaking the legacy query protocol match on the namespaced codes (e.g. AWS.SimpleQueueService.NonExistentQueue) — the same awsQueryCompatible mapping already sent in the x-amzn-query-error header on the JSON path is now applied to the XML <Code> element. Reported by @play4uman.