DynamoDB — can not use both expression and non-expression parameters

TL;DR — Your request set a legacy parameter (KeyConditions, QueryFilter, ScanFilter, AttributesToGet, Expected, AttributeUpdates) and its expression equivalent (KeyConditionExpression, FilterExpression, ProjectionExpression, ConditionExpression, UpdateExpression) in the same call. DynamoDB forbids mixing the two families. Remove the legacy parameter and use expressions only.

What it means

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

DynamoDB has two generations of parameters. The legacy family (KeyConditions, ScanFilter, AttributesToGet, Expected, …) predates expressions; the expression family (KeyConditionExpression, FilterExpression, ProjectionExpression, ConditionExpression, UpdateExpression) replaced it. A single request must commit to one family — supplying both, even for unrelated concerns, is rejected.

Why it happens

• Half-migrated code — you added KeyConditionExpression but left an old KeyConditions on the same params object.
• A projection collision — AttributesToGet (legacy) alongside ProjectionExpression.
• A filter collision — ScanFilter/QueryFilter alongside FilterExpression.
• A write collision — Expected/AttributeUpdates alongside ConditionExpression/UpdateExpression.
• A helper library that injects a legacy default while you set the expression form.

How to fix it

1. Delete the legacy parameter. Keep only the expression form: KeyConditionExpression over KeyConditions, FilterExpression over ScanFilter/QueryFilter, ProjectionExpression over AttributesToGet, ConditionExpression/UpdateExpression over Expected/AttributeUpdates.
2. Move values into placeholders — legacy inline values become ExpressionAttributeValues (:v) and reserved/complex names become ExpressionAttributeNames (#n).
3. Audit the whole params object — the conflict can be between two different concerns (e.g. legacy projection + expression key condition), not just the same one.
4. Prefer expressions everywhere — the legacy parameters are deprecated; standardizing on expressions avoids this class of error.

Modernizing old query code? Prototype the expression-only request in the DynoTable desktop app first, then copy the generated parameters into your app.

Related errors

• Cannot specify projection when Select is COUNT — another mutually-exclusive parameter combination.
• Query key condition not supported — a malformed KeyConditionExpression.
• Learn: Key condition expressions · Expression names & values