v1.3.24 — x-amzn-errortype on every JSON error, AppConfig 404 body, reset() warnings silenced

May 2, 2026 · v1.3.24

1.3.24 is a bug-fix release. Three things you might already have hit, all fixed.

1. x-amzn-errortype header on every JSON-protocol error

Real AWS sends the error type in two places on JSON-protocol responses: __type in the body, and x-amzn-errortype in the response header. boto3 reads the body. Java SDK v2 and Go SDK v2 read the header — and when it's missing they surface SdkClientException: unknown error type instead of the actual code, which makes a perfectly correct 4xx look like a transport bug.

ministack was setting __type but not the header on most services. Now both are set everywhere. The fix lives in the central error_response_json helper plus eleven services that build error bodies inline (apigateway v1/v2, opensearch, scheduler, eks, ses, backup, sqs, cloudwatch, dynamodb, tagging). DDB, KMS, EventBridge, Kinesis, Firehose, Secrets, SSM, CloudWatch Logs, Step Functions, Lambda, API Gateway v2, and AppConfig all now carry the header end-to-end:

$ curl -i -X POST http://localhost:4566/ \
    -H 'X-Amz-Target: DynamoDB_20120810.DescribeTable' \
    -H 'Content-Type: application/x-amz-json-1.0' \
    -d '{"TableName":"missing"}'

HTTP/1.1 400 Bad Request
content-type: application/x-amz-json-1.0
x-amzn-errortype: ResourceNotFoundException
{"__type": "ResourceNotFoundException", "message": "..."}

If you're using the AWS Java SDK v2, Go SDK v2, or the Rust SDK against ministack and have been seeing "unknown error type" in your logs, this fixes it without any change on your side.

2. AppConfig 404 bodies include __type

AppConfig's REST-JSON 404 body used to be {"Code": "...", "Message": "..."}. The header (x-amzn-errortype) was already correct, so SDKs that read the header worked, but generic JSON-error parsers that look only at __type saw an unknown shape and fell back to the HTTP status code. Body now carries both styles — __type next to the existing Code/Message — so every JSON-error parser gets a useful answer.

3. Three reset() warnings silenced

The /_ministack/reset admin endpoint iterates every loaded service module and calls its reset(). Three modules added in 1.3.23 (account, waf-classic, and resourcegroupstaggingapi) are stateless — their data lives in other services' tag stores or is computed per request — so they never needed a reset(). The central reset logger was emitting one WARNING per missing hook per call, which produced three lines of yellow on every invocation. Each module now exposes a no-op reset(); the warnings are gone.

What didn't change

1.3.24 is bug-fix-only. No new services, no new env vars, no behaviour changes outside the three items above. The 30% idle-RAM cut from 1.3.23 stays. The same Docker image (ministackorg/ministack:1.3.24, 270 MB) and the same drop-in compatibility with boto3, Terraform, CDK, and Pulumi.

Upgrade

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

Or pin in compose.yaml:

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