Cannot do operations on a non-existent table (DynamoDB Local)

En bref — C'est la formulation de ResourceNotFoundException par DynamoDB Local, et le piège est que « non-existent » est cadré sur le fichier de base de données que cette instance a ouvert pour ta clé d'accès + région actuelles. Sans -sharedDb, Local garde un ensemble de tables séparé par combinaison identifiants/région — donc la table que tu as créée avec la CLI peut être invisible pour ton application. Lance Local avec -sharedDb (ou fixe des identifiants factices + une région identiques partout), et souviens-toi que -inMemory démarre vide à chaque redémarrage.

Ce que ça signifie

ResourceNotFoundException: Cannot do operations on a non-existent table

Ta requête a atteint un DynamoDB Local en cours d'exécution, qui a cherché la table et ne l'a pas trouvée — dans la base de données qu'il utilise pour l'identité de ta requête. Le vrai AWS formule le même échec différemment (Requested resource not found), donc ce message exact est un fort indice que tu parles à un émulateur.

Pourquoi ça arrive

Split-brain identifiants/région (le classique). Sans -sharedDb, DynamoDB Local nomme son fichier de base de données d'après la clé d'accès et la région de chaque requête. Ta CLI (--profile avec la clé local, région us-east-1) et ton application (clé fake, région local) voient donc deux ensembles de tables différents — chacun a créé la table « pour lui-même ».
-inMemory + un redémarrage — le mode en mémoire ne garde rien sur disque ; chaque redémarrage est une base de données vierge.
Un conteneur neuf sans volume — docker run amazon/dynamodb-local démarre vide ; les tables du conteneur précédent ont disparu à moins d'avoir monté un stockage -dbPath.
La table n'a réellement pas été créée — les scripts de configuration n'ont pas tourné, ou l'ont créée sur un port/une instance différents.
Le même code pointé vers le vrai AWS vs Local — la table existe dans le cloud mais pas dans l'émulateur (ou l'inverse).

Comment corriger

Vois ce que CETTE identité voit — liste les tables avec exactement les identifiants/région/endpoint qu'utilise ton application :
```
AWS_ACCESS_KEY_ID=local AWS_SECRET_ACCESS_KEY=local \
aws dynamodb list-tables --endpoint-url http://localhost:8000 --region us-east-1
```
Si la table manque ici mais existe « quelque part », c'est le cadrage.

Lance Local avec -sharedDb pour que chaque client partage une seule base de données quels que soient les identifiants/la région :

java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb
# docker: docker run -p 8000:8000 amazon/dynamodb-local -jar DynamoDBLocal.jar -sharedDb

Ou fixe une seule identité partout — les mêmes accessKeyId, secretAccessKey et region factices dans le profil CLI, la config du client SDK et la configuration des tests.
Persiste entre les redémarrages — abandonne -inMemory, définis -dbPath, et (dans Docker) monte-le comme volume.
Crée les tables à la configuration — pour les tests, crée la table (et attends-la) dans le bootstrap de la suite pour qu'une instance neuve ne soit jamais une surprise.

Le problème de cadrage est bien plus facile à voir qu'à déduire — l'application de bureau DynoTable se connecte à DynamoDB Local et montre exactement quelles tables une combinaison endpoint + identifiant peut voir, donc le split-brain est visible d'un coup d'œil. Tu prépares des données de départ ? Le convertisseur DynamoDB JSON transforme du JSON brut en éléments typés.

FAQ

Pourquoi DynamoDB Local dit-il que la table n'existe pas alors que je viens de la créer ? Sans -sharedDb, DynamoDB Local garde un fichier de base de données séparé par clé d'accès et région, donc la table que tu as créée avec la CLI peut être invisible pour ton application si leurs identifiants ou leur région diffèrent. Lance Local avec -sharedDb ou fixe des identifiants factices et une région identiques partout.

Pourquoi mes tables DynamoDB Local ont-elles disparu après un redémarrage ? En mode -inMemory, rien n'est gardé sur disque, donc chaque redémarrage est une base de données vierge. Un conteneur Docker neuf sans volume monté démarre vide aussi. Abandonne -inMemory, définis -dbPath, et monte-le comme volume pour persister les tables.

Erreurs liées

ResourceNotFoundException — la variante vrai-AWS (mauvaise région/mauvais compte/mauvais nom de table).
Could not connect to DynamoDB Local (ECONNREFUSED)
DynamoDB Local port 8000 in use
Apprends : Running DynamoDB Local · Connect to Local & LocalStack

Références

DynamoDB local usage notes — AWS DynamoDB Developer Guide (per-credential/Region myaccesskeyid_region.db files, -sharedDb → shared-local-instance.db, -inMemory keeps nothing on disk)
Deploying DynamoDB locally on your computer — AWS DynamoDB Developer Guide (Docker Compose -sharedDb -dbPath ./data + volume pattern, dummy credentials)
amazon/dynamodb-local — Docker Hub (official image; fresh containers start empty without a mounted volume)

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