Cognito CUSTOM_AUTH, EKS Access Entries, X-Ray, Firehose Lambda processor

June 2, 2026 · v1.3.56

Two new flows that unblock entire categories of integrations (Cognito passwordless and EKS modern IAM bindings), a Lambda runtime gap closed for X-Ray, the missing half of the Firehose Kinesis-source fix from v1.3.53, and a deep DynamoDB error-message conformance pass.

Cognito User Pools — CUSTOM_AUTH flow with all three Lambda triggers

InitiateAuth / AdminInitiateAuth / RespondToAuthChallenge / AdminRespondToAuthChallenge now run the full custom-auth state machine through the configured Lambdas: DefineAuthChallenge decides next-step / issueTokens / failAuthentication; CreateAuthChallenge builds public + private challenge parameters carried through the opaque session token (private params never returned to the client); VerifyAuthChallengeResponse evaluates the answer. Session TTL honors the client's AuthSessionValidity (minutes), capped at 3 answered rounds per AWS. Unblocks passwordless / magic-link / SMS-OTP flows that previously failed at InitiateAuth with Unsupported AuthFlow: CUSTOM_AUTH. Reported by @aahoughton. Contributed by @AdigaAkhil.

EKS Access Entries — modern IAM bindings replacing the aws-auth ConfigMap

8 new ops at /clusters/{name}/access-entries[/{principalArn}[/access-policies[/{policyArn}]]]:

• CreateAccessEntry, DescribeAccessEntry, ListAccessEntries, UpdateAccessEntry, DeleteAccessEntry
• AssociateAccessPolicy, DisassociateAccessPolicy, ListAssociatedAccessPolicies

accessScope validated against {cluster, namespace} with namespaces required when scope is namespace-bound; deleting an access entry cascades its associated policies. Unblocks Crossplane accessentry.eks.aws.upbound.io, Terraform aws_eks_access_entry + aws_eks_access_policy_association, and any tool using the post-1.29 EKS IAM binding API. Reported by @b-rajesh.

Lambda — _X_AMZN_TRACE_ID injected for TracingConfig.Mode=Active

The runtime env var the AWS X-Ray SDK reads on every segment was never being set, so aws-xray-sdk-python raised Missing AWS Lambda trace data for X-Ray on any active-tracing function. Now synthesized per invocation in the AWS-canonical format (Root=1-<8hex>-<24hex>;Parent=<16hex>;Sampled=1) and threaded into:

• The warm Python / Node worker pool — the bootstrap pops the value from the per-invocation event into os.environ / process.env before calling the handler. The X-Ray SDK re-reads the env var per segment via os.getenv, so each invocation gets a fresh trace ID with no cross-invocation leakage.
• The provided-runtime executor (Go / Rust / custom) — per-spawn proc_env includes the trace ID.
• The one-shot local subprocess executor — same per-invocation env.

The docker RIE executor (used for PackageType=Image and LAMBDA_EXECUTOR=docker) is documented as upstream-unsupported — AWS RIE itself drops X-Ray (the upstream README says so explicitly), and the pool reuses containers so a baked env would go stale. Active mode on that path now logs a clear warning. Reported by @arivazhaganjeganathan-abc.

Firehose — Lambda processor invoked in the delivery pipeline

ProcessingConfiguration.Processors[].Type=Lambda was persisted on the destination but never consulted at invocation time — records flowed straight to S3 without the configured transformation. The full AWS contract is now honored: per-batch event {invocationId, deliveryStreamArn, region, records:[{recordId, approximateArrivalTimestamp, data}]}, response {records:[{recordId, result, data}]} with result ∈ {Ok, Dropped, ProcessingFailed}. Ok → transformed data ships downstream; Dropped / ProcessingFailed → omitted; Lambda not-found / crash / malformed body → records pass through unchanged (best-effort per AWS — a processor problem must never break the producer). Applies to both PutRecord / PutRecordBatch direct writes and the KinesisStreamAsSource fan-out introduced in v1.3.53. Reported by @arivazhaganjeganathan-abc.

Cognito CUSTOM_AUTH — issueTokens on the cap-boundary attempt now wins over MaxAttempts

A correct answer on the 3rd round (cap boundary) was being silently rejected with Max authentication attempts exceeded because the cap check fired before the issueTokens branch. The cap is meant to prevent a next (4th) round, not penalize success on the boundary. Reordered: failAuthentication → issueTokens → max-attempts → next round. Applies to both RespondToAuthChallenge and AdminRespondToAuthChallenge.

DynamoDB — AWS-canonical error-message parity across 24 operations

Conformance pass against dynamodb-conformance.org. Highlights:

• Set-duplicates include the collection contents (Input collection [a, a] contains duplicates.).
• UpdateItem syntax errors carry token-context (token: "INVALID", near: "INVALID SYNTAX") and UpdateExpression pre-rejects mutation of hash / range key attributes regardless of whether the item exists.
• Query empty KeyConditionExpression short-circuits before the unused-EAV check.
• Scan Limit=0 quotes the value (Value '0' at 'limit'); negative Segment uses the AWS-canonical 1 validation error detected envelope with lowercase segment.
• Redundant-parentheses and begins_with non-string operand checks pre-fire on FilterExpression / KeyConditionExpression at parse time so empty tables still reject (instead of silently passing).
• BatchExecuteStatement per-statement Error.Code drops the Exception suffix to match the AWS BatchStatementErrorCodeEnum (DuplicateItem / ResourceNotFound).
• TransactGetItems reports per-action missing-key errors via TransactionCanceledException cancellation reasons (not a request-level error).
• Size-exceeded envelopes on BatchWriteItem / TransactWriteItems / TransactGetItems include the AWS-shape Java-toString dump.
• GetItem / TransactGetItems ProjectionExpression parses syntactically and rejects reserved keywords up front.

Upgrade

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

Or pin in compose.yaml:

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