Filter Expression can only contain non-primary key attributes

TL;DR — Tu as placé un attribut de clé primaire (clé de partition ou clé de tri — de la table ou de l'index que tu interroges) dans une FilterExpression. DynamoDB l'interdit : les attributs de clé vont dans la KeyConditionExpression, et un filtre ne peut référencer que des attributs hors clé. Déplace la condition de clé là où elle doit être.

Ce que ça signifie

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 s'exécute après la lecture des éléments, pour écarter les lignes dont tu ne veux pas ; KeyConditionExpression s'exécute avant, pour sélectionner par clé quels éléments sont lus. Référencer une clé de partition/tri dans le filtre mélange ces rôles, donc DynamoDB rejette la requête avec une ValidationException HTTP 400 — côté client et non réessayable tant que tu ne la restructures pas.

Pourquoi ça arrive

Une condition de clé écrite comme un filtre — FilterExpression: 'sk = :v' où sk est la clé de tri ; elle appartient à la KeyConditionExpression.
Filtrer sur la clé de l'index — quand tu fais un Query sur un GSI/LSI, la clé de partition/tri propre à cet index est un « attribut de clé primaire » pour cette requête et ne peut pas apparaître dans le filtre.
Copier-coller un filtre de scan sur une requête où l'un des attributs filtrés se trouve être une clé.
Essayer d'ajouter une seconde condition sur la clé de tri via le filtre (par ex. une plage) au lieu de l'exprimer dans la condition de clé.

Comment le corriger

Déplace les conditions de clé dans KeyConditionExpression :

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

Utilise le bon index. Si tu dois filtrer/sélectionner sur un attribut qui n'est pas une clé, modélise-le comme clé de partition/tri d'un GSI et interroge cet index par clé.
Garde le filtre pour les attributs hors clé uniquement — il réduit les résultats mais consomme quand même de la capacité de lecture pour chaque élément scanné, alors appuie-toi sur les clés/index pour la sélection.
Tu interroges un GSI ? Rappelle-toi que ses attributs de clé sont aussi interdits dans le filtre — mets-les en condition dans la condition de clé.

Lance-le dans DynoTable

Le panneau de requête de DynoTable garde conditions de clé et filtres dans des champs séparés — les contraintes sur clé de partition et de tri n'atterrissent jamais dans FilterExpression. Ouvre une table avec ⌘K, pose la condition de clé, puis ajoute les filtres hors clé ; copie la requête générée dans ton SDK.

Sers-toi du Query Builder pour prototyper des requêtes sur GSI où les clés d'index doivent rester dans la KeyConditionExpression. Change de profil avec ⌘P ; Test Connection dans Settings → Profiles confirme que l'index existe. Vois Se connecter à AWS et Installation.

Sources

Query — Amazon DynamoDB API Reference (vérifié le 2026-07-13)
Filter expressions for Query (vérifié le 2026-07-13)

Erreurs liées

Query key condition not supported — un opérateur/une forme invalide dans la condition de clé elle-même.
Query condition missed key schema element — la requête n'a pas fourni la clé de partition.
Exemple de code : Query en Node.js — condition de clé et filtre correctement séparés.
Apprends : Stratégies de filtrage · Expressions de condition de clé

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.