Attempting to modify a GSI that is being created

En bref — Pendant qu'un index secondaire global se construit (IndexStatus = CREATING), DynamoDB rejette les changements structurels conflictuels. Durant la phase initiale d'allocation des ressources, tu ne peux pas modifier le nouvel index, changer le débit provisionné de l'index ou de la table, ajouter ou supprimer d'autres index, ni supprimer la table. Une fois le backfill démarré, tu peux supprimer l'index en cours ou changer à nouveau le débit table/GSI, mais l'ajout ou la suppression d'autres index et la suppression de la table restent bloqués jusqu'à ce qu'il soit ACTIVE. Fais les changements de GSI un à la fois — une création ou une suppression par UpdateTable.

Ce que ça signifie

ValidationException: Attempting to modify a GSI that is being created

Créer un GSI sur une table peuplée déclenche un backfill — DynamoDB rejoue les éléments existants dans le nouvel index en arrière-plan. Pendant toute cette phase, l'IndexStatus de l'index est CREATING. Durant le backfill, DynamoDB rejette les changements structurels supplémentaires sur l'index ou la table pour que la construction reste cohérente. C'est un HTTP 400 ValidationException ; réessayer immédiatement échoue jusqu'à ce que l'index se termine.

Pourquoi ça arrive

Opérations d'index qui se chevauchent — un UpdateTable (ou un apply IaC) tente de modifier/supprimer un GSI, ou d'en ajouter un second, pendant que le premier se construit encore.
Batch CloudFormation/Terraform — l'outil tente plusieurs changements de GSI dans une seule mise à jour ; DynamoDB n'autorise qu'une création ou suppression de GSI par UpdateTable.
Changement de débit pendant l'allocation des ressources — pendant que le nouvel index alloue encore ses ressources (Backfilling: false), tu ne peux pas modifier le débit provisionné de cet index ni de la table ; ces changements sont à nouveau autorisés une fois le backfill démarré.
Supprimer la table trop tôt — un teardown qui fait la course avec le backfill.

Comment le corriger

Attends ACTIVE. Interroge DescribeTable et vérifie chaque GlobalSecondaryIndexes[].IndexStatus ; ne continue qu'une fois qu'il est ACTIVE.
```
aws dynamodb describe-table --table-name <Table> \
  --query "Table.GlobalSecondaryIndexes[].{Name:IndexName,Status:IndexStatus}"
```
La description de l'index porte aussi un booléen Backfilling (false = allocation des ressources, true = backfill), et la métrique CloudWatch OnlineIndexPercentageProgress suit la construction.
Séquence les changements d'index — une création/suppression par UpdateTable ; n'ajoute pas un nouveau GSI pendant qu'un autre se construit.
Dans CloudFormation/Terraform, répartis les ajouts de GSI sur des déploiements séparés pour que chaque backfill se termine avant le changement suivant.
Diffère les autres changements d'index et la suppression de la table jusqu'à ce que l'index soit ACTIVE. Besoin d'abandonner ? Une fois le backfill démarré, tu peux annuler la construction en supprimant l'index en cours de création.

Avant de réessayer dans DynoTable

Tant qu'un GSI est en CREATING, ouvre la table dans DynoTable et surveille le statut de l'index dans les détails de la table avant de mettre un autre UpdateTable en file. L'app rafraîchit DescribeTable pendant que tu navigues — quand IndexStatus bascule sur ACTIVE, l'index apparaît dans le sélecteur de query pattern et tu peux l'interroger depuis le mode Visuel ou depuis le query builder.

N'empile pas des changements de GSI CloudFormation/Terraform dans un seul apply tant que DynoTable affiche encore CREATING. Séquence tes déploiements ; sers-toi de DynoTable comme panneau de statut de référence entre deux applies. Si tu dois annuler une construction après le début du remplissage, supprime cet index depuis ton IaC/ta CLI, puis confirme qu'il disparaît de la liste d'index de DynoTable.

Sources

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

Erreurs liées

Local secondary indexes must be specified at table creation — l'équivalent LSI (les LSI ne peuvent pas être ajoutés du tout).
ResourceInUseException — opérer sur une table/un index qui n'est pas dans un état modifiable.
Requested resource not found / index not found — interroger un index qui n'est pas prêt ou n'existe pas.
Apprends : GSI vs LSI · GSI internals

Références

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