The table does not have the specified index

TL;DR — L'IndexName de ton Query/Scan n'existe pas sur cette table (depuis la région + le compte de ce client), est mal orthographié, ou le GSI est encore en CREATING et pas encore interrogeable. Confirme le nom et le statut exacts de l'index avec DescribeTable, puis corrige l'appel.

Ce que ça signifie

ValidationException: The table does not have the specified index: <IndexName>

# what the engine actually returns, reproduced against DynamoDB Local:
ValidationException: The table does not have the specified index: no-such-index

Tu as demandé à DynamoDB de faire un Query ou un Scan sur un index secondaire spécifique par nom, et la table (telle que ce client la voit) n'a aucun index de ce nom dans un état utilisable. C'est une ValidationException HTTP 400 — côté client et non réessayable tant que le nom/statut n'est pas correct.

Pourquoi ça arrive

Faute de frappe ou mauvaise casse — les noms d'index sont sensibles à la casse ; GSI1 ≠ gsi1.
L'index appartient à une autre table — tu as copié l'IndexName du schéma d'une autre table.
Le GSI n'est pas encore ACTIVE — un index secondaire global fraîchement créé ne peut pas être interrogé tant que son statut n'est pas passé de CREATING → ACTIVE (il fait d'abord un remplissage rétroactif).
Mauvaise région/mauvais compte — le client pointe vers une région où la table (ou son index) n'existe pas (le même problème de concordance qu'une table manquante).
Dérive de DynamoDB Local — un fichier shared-local-instance.db local périmé, antérieur à l'index ; recrée-le.

Comment le corriger

Liste les vrais noms d'index et leur statut :

aws dynamodb describe-table --table-name <Table> \
  --query "Table.GlobalSecondaryIndexes[].{Name:IndexName,Status:IndexStatus}"

Copie le nom mot pour mot dans IndexName — respecte la casse exactement.
Attends ACTIVE. Si le GSI est en CREATING, la requête ne fonctionne qu'une fois le remplissage rétroactif terminé (DescribeTable affiche IndexStatus).
Confirme région + compte avec aws sts get-caller-identity et fixe la region du client.
Sur DynamoDB Local, supprime le fichier de base de données local et relance la configuration de ta table/ton index pour que l'index existe localement.

Tu travailles sur plusieurs tables et index ? La boîte de dialogue de table de DynoTable liste les GSI de chaque table et leur statut, pour que tu puisses choisir un index qui existe réellement — et qui est ACTIVE — au lieu de deviner le nom. Elle crée et supprime aussi un GSI quand l'index dont tu avais besoin fait vraiment défaut.

Interroge dans DynoTable

Ouvre la table dans DynoTable avec ⌘K et déplie le panneau Indexes — chaque nom de GSI et son IndexStatus y sont listés, sans appel CLI. Choisis l'index dans la liste déroulante du panneau de requête plutôt que de taper IndexName à la main ; DynoTable ne propose que les index qui existent sur la table connectée.

Si le GSI est encore en CREATING, rafraîchis les métadonnées de la table depuis la barre latérale jusqu'à ce que le statut bascule sur ACTIVE. Sers-toi du Query Builder pour composer une requête sur GSI et copie l'IndexName généré dans ton code SDK. Change de profil avec ⌘P quand l'index existe dans une Région mais pas dans une autre. Configuration : Se connecter à AWS, Installation.

Sources

Managing Global Secondary Indexes in DynamoDB (vérifié le 2026-07-13)
Query — Amazon DynamoDB API Reference (vérifié le 2026-07-13)

Erreurs liées

ResourceNotFoundException — c'est toute la table (pas juste un index) qui est introuvable.
Query key condition not supported — l'index existe mais ta condition de clé est incorrecte pour lui.
Exemple de code : Interroger un GSI en Node.js — IndexName correctement câblé.
Apprends : GSI vs LSI · Les GSI sont cohérents à terme · Index

Références

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