Step Functions JSONata standard library, RDS Data API readiness, non-blocking CreateDBInstance

May 19, 2026 · v1.3.44

Three things land together: the Step Functions JSONata evaluator picks up the rest of the standard library, the RDS Data API stops silently acking writes against a still-booting container, and CreateDBInstance goes back to returning instantly with status=creating — matching real AWS instead of blocking on the boot.

Step Functions JSONata standard library

The JSONata evaluator now ships ~30 built-in functions on top of the existing core ($merge, $count, $length, $not, $string, $number):

• String: $uppercase, $lowercase, $substring, $trim, $contains, $split, $join, $replace, $pad
• Numeric: $sum, $average, $max, $min, $abs, $floor, $ceil, $round, $power, $sqrt, $formatNumber
• Array: $sort (including the function($l, $r){…} comparator form), $reverse, $distinct, $append
• Object: $keys, $values, $lookup (over both objects and arrays-of-objects), $exists
• Type: $type, $boolean
• Date/Time: $now() / $now(picture) / $now(picture, timezone) with the XPath-3.1 picture-string subset, $millis
• Utility: $uuid, $base64encode, $base64decode

The motivating example — using $exists in a Choice Condition to route on field presence — now works whether the field is present, explicitly null, or missing entirely. Before this release the same expression failed the execution with States.QueryEvaluationError: Unsupported JSONata expression: $exists(...):

{
  "Type": "Choice",
  "Choices": [
    {
      "Condition": "{% $exists($states.input.userId) %}",
      "Next": "HasUser"
    }
  ],
  "Default": "NoUser"
}

Parity-edge cases match the JSONata spec: $contains / $split / $replace accept regex literals (/pattern/flags) and $replace supports $1/$& substitution refs; $lookup walks arrays of objects; $boolean treats an array of only-falsy values as false; $exists distinguishes a missing path from an explicit null; $round uses banker's rounding (round-half-to-even). Implemented natively in Python — no new runtime dependency.

RDS Data API no longer silently acks writes against an unbooted container

When a Docker-backed RDS instance was still bootstrapping, ExecuteStatement / BatchExecuteStatement previously fell back to the in-memory SQL stub on any connection error and returned a 200 acknowledging CREATE USER / GRANT statements that never reached MySQL. Tests that relied on the stub for control-plane-only clusters still work; container-backed clusters whose endpoint can't be reached now surface DatabaseUnavailableException (HTTP 504, the canonical AWS error code) so callers see the same transient-error shape they'd see against real RDS. Real SQL errors (lock-wait timeout, etc.) still surface as BadRequestException, not transient-unavailable.

CreateDBInstance returns immediately with status=creating

Real AWS CreateDBInstance returns within milliseconds and lets the caller observe the transition to available via DescribeDBInstances. Until this release the previous fix had the call block inline for up to 60s waiting for the container to be reachable, which broke parity for any framework that polls the status field. Now CreateDBInstance returns instantly with DBInstanceStatus="creating" and readiness finalisation (authenticated-connection probe, MySQL master-user GRANT, transition to available, Aurora cluster endpoint sync) runs on a daemon thread. There's no wall-clock timeout — same as real RDS — and the daemon tracks the backing container's liveness instead: while the container is up the instance stays creating; if the container exits before becoming reachable the instance flips to failed. Image-side password mismatches (the one pathological case where the loop would otherwise spin invisibly) log at WARNING level with a remediation hint, so the failure mode is observable in ministack logs rather than silent.

Standard AWS ECS Docker labels on RunTask containers

Every container MiniStack spawns for an ECS task now carries the five canonical com.amazonaws.ecs.* labels real ECS sets:

com.amazonaws.ecs.cluster                  = <cluster-arn>
com.amazonaws.ecs.container-name           = <container-name>
com.amazonaws.ecs.task-arn                 = <task-arn>
com.amazonaws.ecs.task-definition-family   = <family>
com.amazonaws.ecs.task-definition-version  = <revision>

Keys and values match the AWS ECS container metadata file spec. Host-side log shippers, monitoring agents, and docker ps --filter "label=…" queries can now identify MiniStack-spawned containers the same way they would against real ECS.

Upgrade

docker pull ministackorg/ministack:1.3.44
docker run -d -p 4566:4566 ministackorg/ministack:1.3.44

Or pin in compose.yaml:

services:
  ministack:
    image: ministackorg/ministack:1.3.44
    ports:
      - "4566:4566"