bug: DynamoDB Query rejects KeyConditions with FilterExpression accepted by AWS (Pro dev105)

[AndreKurait]

LocalStack rejects Query requests combining legacy KeyConditions with FilterExpression, while live AWS accepts this specific combination and evaluates the predicates. The equivalent KeyConditionExpression control works on both.

Environment

• Unmodified localstack/localstack-pro:dev, version 2026.10.0.dev105, build 3a0ece14; Pro license activation verified.
• Exact linux/amd64 image: sha256:acec8be1241f45d56519b20746d0208041e331ad2913be1eb03fd8d582121a2d.
• Also reproduced on native linux/arm64: sha256:8f4da21eb967b43d53b3e2c66597979bc3bf58eaf6816295c3fa2b138f24b4e7.
• Both are from dev image index sha256:b38e4fcb56751f999637f3395fd9ef4a593a4b96b57887d9b62ce44c6f22b5aa, pulled 2026-10-12.
• Docker Desktop on an ARM Mac (AMD64 run under emulation), EC2_VM_MANAGER=mock, no DynamoDB provider overrides, extensions, or source patches.
• Region us-east-1, boto3 1.43.111. ARM comparison: 2026-10-12 16:44:05–16:44:09 UTC; exact AMD64 comparison: 16:47:07–16:47:12 UTC. Same outcomes on both architectures.

Observed versus expected

LocalStack returns HTTP 400 before query evaluation:

ValidationException: Can not use both expression and non-expression parameters in the same request: Non-expression parameters: {KeyConditions} Expression parameters: {FilterExpression}

The live AWS baseline completed in us-east-1 on 2026-10-12 at 16:12:35 UTC, using an isolated table and synthetic data. Four real Query calls compared old/new key representations with matching/nonmatching filter values. All used consistent reads.

Request	Matching filter	Nonmatching filter
AWS: KeyConditions + FilterExpression	Same seeded item, Count=1, ScannedCount=1	Items=[], Count=0, ScannedCount=1
AWS: KeyConditionExpression + FilterExpression	Identical	Identical
LocalStack: KeyConditions + FilterExpression	ValidationException	ValidationException
LocalStack: KeyConditionExpression + FilterExpression	Matches AWS	Matches AWS

AWS's legacy-parameter overview warns against mixing legacy and expression parameters, while its KeyConditions page also describes applying FilterExpression after the legacy key query. This report requests parity with the specifically observed service behavior, not blanket acceptance of every legacy/expression combination.

Minimal reproducer

Start a disposable container with your own auth token set in the environment:

docker run --rm --name localstack-compat-repro \
  --platform linux/amd64 \
  -p 127.0.0.1:14566:4566 \
  -e LOCALSTACK_AUTH_TOKEN \
  -e EC2_VM_MANAGER=mock \
  localstack/localstack-pro@sha256:acec8be1241f45d56519b20746d0208041e331ad2913be1eb03fd8d582121a2d

After readiness, install boto3 and run the script below. This standalone reproducer was executed against the exact AMD64 image above. All AWS credentials are dummy values and the endpoint is loopback LocalStack. Fixtures are cleaned up.

"""LocalStack-only reproducer. Uses fake AWS credentials and creates no instances."""
import json
import uuid

import boto3
from botocore.config import Config
from botocore.exceptions import ClientError

options = dict(
    endpoint_url="http://127.0.0.1:14566",
    region_name="us-east-1",
    aws_access_key_id="test",
    aws_secret_access_key="test",
    config=Config(retries={"max_attempts": 0}, proxies={}),
)
ec2, asg, ddb = [boto3.client(name, **options) for name in ("ec2", "autoscaling", "dynamodb")]
name = "compat-repro-" + uuid.uuid4().hex[:8]


def record(label, call):
    try:
        value = call()
        print(json.dumps({"case": label, "result": value}, default=str))
        return True
    except ClientError as error:
        print(json.dumps({"case": label, "error": error.response["Error"]}))
        return False


ddb.create_table(
    TableName=name, AttributeDefinitions=[{"AttributeName": "pk", "AttributeType": "S"}],
    KeySchema=[{"AttributeName": "pk", "KeyType": "HASH"}], BillingMode="PAY_PER_REQUEST",
)
ddb.get_waiter("table_exists").wait(TableName=name, WaiterConfig={"Delay": 1, "MaxAttempts": 30})
try:
    item = {"pk": {"S": "row"}, "diNumber": {"S": "7"}, "tested": {"S": "PENDING"}}
    ddb.put_item(TableName=name, Item=item)
    for version in ["old", "new"]:
        for number in ["7", "8"]:
            query = dict(
                TableName=name, ConsistentRead=True, FilterExpression="diNumber = :diNumber",
                ExpressionAttributeValues={":diNumber": {"S": number}},
            )
            if version == "old":
                query["KeyConditions"] = {
                    "pk": {"ComparisonOperator": "EQ", "AttributeValueList": [{"S": "row"}]}
                }
            else:
                query["KeyConditionExpression"] = "pk = :pk"
                query["ExpressionAttributeValues"][":pk"] = {"S": "row"}
            record(f"query-{version}-{number}", lambda: ddb.query(**query))

finally:
    ddb.delete_table(TableName=name)

On the affected image, both query-old-* cases fail validation. query-new-7 returns the item and query-new-8 returns an empty result. Live AWS accepted both key representations with the same results.

[EddEcho]

Hi @AndreKurait We reproduced the issue on our latest dev build and confirmed that AWS accepts these requests, so it’s now with our engineering team for review. We’ll update this thread once a fix is available so you can test it.

[EddEcho]

Hi @AndreKurait this is now fixed in our latest dev build. Could you run docker pull localstack/localstack-pro:dev, give it a try, and let us know if it works for you?