DynamoDB ResourceInUseException

TL;DR — Tu as tenté une opération de table sur une table qui existe déjà ou est encore en transition (CREATING / UPDATING / DELETING). Vérifie d'abord le statut de la table, ou rends la création idempotente en ignorant « already exists ».

Ce que ça signifie

ResourceInUseException: Table already exists: <name>
ResourceInUseException: Attempt to change a resource which is still in use: Table is being created/deleted

# what the engine actually returns, reproduced against DynamoDB Local:
ResourceInUseException: Cannot create preexisting table

Les opérations du plan de contrôle (CreateTable, DeleteTable, UpdateTable) exigent que la table soit dans un état compatible. Cette erreur signifie qu'elle ne l'est pas — soit elle existe déjà, soit elle est en pleine transition et DynamoDB n'acceptera pas une autre opération tant qu'elle ne se sera pas stabilisée sur ACTIVE. DynamoDB la renvoie avec un statut HTTP 400, et elle n'est pas réessayable en l'état — réessayer la requête identique échoue tant que l'état ne change pas (attends la fin de la transition, ou modifie la requête).

Pourquoi ça arrive

Ré-exécution de CreateTable pour une table qui existe déjà (une migration/un déploiement répété, des tests qui ne font pas de nettoyage).
Opération pendant une transition — créer un index, supprimer ou mettre à jour pendant que la table est encore CREATING/UPDATING.
Une race — deux processus créant la même table simultanément.

Comment le corriger

Vérifie le statut avant d'agir. DescribeTable → ne procède que lorsque TableStatus vaut ACTIVE ; utilise un waiter (waitUntilTableExists) pour bloquer jusqu'à ce qu'elle se stabilise.
Rends la création idempotente. Attrape ResourceInUseException sur CreateTable et traite-la comme un succès (la table que tu voulais existe).
Sérialise les opérations de table dans les tests/migrations pour que deux ne s'exécutent pas en même temps ; nettoie les tables de test dans le teardown.

Exemple

import {DynamoDBClient, CreateTableCommand, ResourceInUseException} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({});

try {
  await client.send(new CreateTableCommand(tableDef));
} catch (err) {
  if (!(err instanceof ResourceInUseException)) throw err;
  // Table already exists — that's fine, carry on.
}

FAQ

Que signifie ResourceInUseException dans DynamoDB ? Une opération du plan de contrôle (CreateTable, DeleteTable, UpdateTable) a ciblé une table qui existe déjà ou est encore en transition à travers CREATING, UPDATING ou DELETING. DynamoDB n'acceptera pas une autre opération tant que la table ne se stabilise pas sur ACTIVE.

Comment rendre CreateTable idempotent ? Attrape la ResourceInUseException et traite-la comme un succès — la table que tu voulais existe. Sinon, vérifie d'abord DescribeTable et ne crée que lorsque la table est absente, en utilisant un waiter comme waitUntilTableExists pour bloquer jusqu'à ce qu'elle se stabilise.

Chemin dans DynoTable

Quand une migration relance CreateTable, DynoTable affiche la table dès qu'elle existe — ouvre-la avec ⌘K → Open table by name pendant que ton script réessaie. Paramètres de la table sur un onglet ouvert affiche TableStatus (CREATING, UPDATING, ACTIVE), de quoi attendre ACTIVE avant d'émettre le changement de plan de contrôle suivant. Pour itérer en local, pointe un profil Local sur http://localhost:8000 (Running DynamoDB Local) et sers-toi du convertisseur JSON DynamoDB pour charger des éléments de départ une fois la table stabilisée.

Pour les tables cloud coincées en UPDATING, Paramètres de la table liste aussi les remplissages de GSI en cours — attends ACTIVE sur chaque index avant le prochain UpdateTable de ton script de déploiement.

Face à DynamoDB Local, la même ResourceInUseException apparaît quand un test relance CreateTable sur une instance en mémoire qui n'a jamais été vidée — traite Local comme le cloud : attrape l'erreur ou attends ACTIVE.

Erreurs liées

ResourceNotFoundException — la table n'existe pas.
ThrottlingException — trop d'opérations du plan de contrôle.
En savoir plus : Migrations DynamoDB

Sources

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