Filter Expression can only contain non-primary key attributes

TL;DR — Du hast ein Primärschlüssel-Attribut (Partition Key oder Sort Key — der Tabelle oder des abgefragten Index) in eine FilterExpression gesteckt. Das verbietet DynamoDB: Schlüsselattribute gehören in die KeyConditionExpression, und ein Filter darf nur Nicht-Schlüsselattribute referenzieren. Verschieb die Schlüsselbedingung dorthin, wo sie hingehört.

Was es bedeutet

ValidationException: Filter Expression can only contain non-primary key attributes:
Primary key attribute: <name>

# what the engine actually returns, reproduced against DynamoDB Local:
ValidationException: Filter Expression can only contain non-primary key attributes: Primary key attribute: pk

FilterExpression läuft nachdem Items gelesen wurden, um Zeilen zu verwerfen, die du nicht willst; KeyConditionExpression läuft davor, um per Schlüssel auszuwählen, welche Items gelesen werden. Ein Partition-/Sort Key im Filter zu referenzieren vermischt diese Rollen, also weist DynamoDB es mit einer HTTP-400-ValidationException zurück — clientseitig und nicht wiederholbar, bis du umstrukturierst.

Warum es passiert

• Eine Schlüsselbedingung als Filter geschrieben — FilterExpression: 'sk = :v', wobei sk der Sort Key ist; sie gehört in die KeyConditionExpression.
• Filtern auf den Schlüssel des Index — wenn du eine GSI/LSI mit Query abfragst, sind deren eigene Partition-/Sort Keys für diese Abfrage „Primärschlüssel-Attribute" und dürfen nicht im Filter erscheinen.
• Copy-Paste eines Scan-Filters in eine Query, bei dem ein gefiltertes Attribut zufällig ein Schlüssel ist.
• Der Versuch, über den Filter eine zweite Bedingung auf den Sort Key hinzuzufügen (z. B. einen Range), statt sie in der Schlüsselbedingung auszudrücken.

So behebst du es

1. Move key conditions into KeyConditionExpression:

   KeyConditionExpression: 'pk = :pk AND begins_with(sk, :prefix)',
   // FilterExpression: only NON-key attributes, e.g. 'status = :active'

   KopierenKopiert
2. Nimm den richtigen Index. Wenn du auf einem Attribut filtern/selektieren musst, das kein Schlüssel ist, modellier es als Partition-/Sort-Key eines GSI und frag diesen Index über den Schlüssel ab.
3. Reservier den Filter für Nicht-Schlüsselattribute — er stutzt die Ergebnisse, verbraucht aber trotzdem Read Capacity für jedes gescannte Item; stütz die Auswahl also auf Schlüssel und Indizes.
4. Fragst du einen GSI ab? Denk daran, dass auch dessen Schlüsselattribute im Filter tabu sind — bedinge sie in der Key Condition.
5. Prüf generierte Requests. Logg KeyConditionExpression und FilterExpression zusammen — Schlüsselattribute im Filter sind ein häufiger Copy-Paste-Fehler aus Scan-Code.

In DynoTable ausführen

DynoTable's query panel keeps key conditions and filters in separate fields — partition and sort key constraints never land in FilterExpression. Öffne eine Tabelle mit ⌘K, set the key condition, then add non-key filters; copy the generated request into your SDK.

Nutze den Query Builder to prototype GSI queries where index keys must stay in KeyConditionExpression. Wechsle Profile mit ⌘P; Verbindung testen on Einstellungen → Profile confirms the index exists. Siehe Mit AWS verbinden und Installation.

Quellen

• Query — Amazon DynamoDB API Reference (verifiziert 2026-07-13)
• Filter expressions for Query (verifiziert 2026-07-13)

Verwandte Fehler

• Query key condition not supported — ein ungültiger Operator/eine ungültige Form in der Schlüsselbedingung selbst.
• Query condition missed key schema element — die Abfrage hat den Partition Key nicht geliefert.
• Code example: Query in Node.js — Schlüsselbedingung und Filter korrekt getrennt.
• Learn: Filterstrategien · Key-Condition-Expressions

Referenzen

• Query — Amazon DynamoDB API Reference
• Filter expressions for Query — Amazon DynamoDB Developer Guide
• Using Global Secondary Indexes in DynamoDB — Amazon DynamoDB Developer Guide

Zuletzt verifiziert am 2026-07-13 gegen die offizielle, oben verlinkte AWS-Dokumentation.