Three reported bugs fixed: CW Logs identifier, ElastiCache CacheNode, APIGW v1 UpdateStage

May 20, 2026 · v1.3.45

Three small, surgical fixes for three distinct reports.

CloudWatch Logs GetLogEvents / FilterLogEvents accept logGroupIdentifier

Per the AWS API reference, both ops let callers identify the target log group with either logGroupName or logGroupIdentifier (the parameter accepts either a bare group name or a full ARN of the form arn:aws:logs:<region>:<account>:log-group:<name>[:*]). MiniStack only handled logGroupName, so SDK code that has the group ARN cached and passes it via logGroupIdentifier would fail with:

ResourceNotFoundException: The specified log group does not exist: None

Both ops now resolve the group from whichever parameter is set; if both are passed, logGroupName wins (AWS rejects the combination, but ministack prefers the explicit name for backwards-compat). The wildcard :* suffix on the ARN form is stripped before lookup. StartQuery and StartLiveTail use a different plural shape (logGroupIdentifiers) and are out of scope for this fix. Reported by @msulima.

ElastiCache DescribeCacheClusters emits the full CacheNode shape

hashicorp/terraform-provider-aws v6.45.0 reads CacheNodeCreateTime off the response struct without a nil check during the post-apply read, so any aws_elasticache_cluster resource fails with:

Error: Unexpected nil pointer in: {CacheNodeCreateTime:<nil> CacheNodeId:0x... CacheNodeStatus:0x... ...}

The Redis instance actually deploys, but Terraform can't confirm availability, so the resource stays stuck in an error state. The root cause was in MiniStack's XML emitter: per-node output only included CacheNodeId / CacheNodeStatus / Endpoint even though the in-memory model already tracked CacheNodeCreateTime and ParameterGroupStatus. The emitter now produces the full botocore CacheNode shape: CacheNodeCreateTime (ISO8601), ParameterGroupStatus, CustomerAvailabilityZone (derived from the cluster's PreferredAvailabilityZone), and SourceCacheNodeId when non-empty. CustomerOutpostArn stays unset — we don't model Outposts, and real AWS omits the element rather than emitting it empty. Reported by @trackme-ddisley.

API Gateway v1 UpdateStage parses boolean fields from patch strings

AWS's UpdateStage uses patchOperations, and the AWS API docs are explicit that every patch value is a string — even for boolean fields like tracingEnabled and cacheClusterEnabled:

{"op": "replace", "path": "/tracingEnabled", "value": "true"}

Until now, MiniStack's v1 PATCH handler routed root-stage operations through a generic _apply_patch that assigned the value as-is. SDK clients that read the stage back then choked at the deserializer:

error: updating API Gateway Stage (ags-...-v1):
operation error API Gateway: UpdateStage, https response error StatusCode: 200,
deserialization failed, failed to decode response body with invalid JSON,
expected Boolean to be of type *bool, got string instead

The handler now coerces patch values to bool when the path is exactly /tracingEnabled or /cacheClusterEnabled. Stage variables whose name happens to be tracingEnabled aren't affected because the path match is exact, not substring. The previously-existing method-settings patch handler (which already coerced booleans on per-method paths) is unchanged. Contributed by @duc12597.

Upgrade

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

Or pin in compose.yaml:

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