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

TL;DR — Das ist DynamoDB Locals Formulierung für ResourceNotFoundException, und die Falle ist, dass „non-existent" auf die Datenbankdatei begrenzt ist, die diese Instanz für deinen aktuellen Access Key + deine Region geöffnet hat. Ohne -sharedDb hält Local pro Credentials-/Region-Kombination ein separates Tabellenset — die Tabelle, die du mit der CLI erstellt hast, kann also für deine App unsichtbar sein. Führe Local mit -sharedDb aus (oder fixiere überall identische Dummy-Credentials + Region), und denk daran, dass -inMemory bei jedem Neustart leer startet.

Was es bedeutet

ResourceNotFoundException: Cannot do operations on a non-existent table

Deine Anfrage hat ein laufendes DynamoDB Local erreicht, das nach der Tabelle gesucht und sie nicht gefunden hat — in der Datenbank, die es für die Identität deiner Anfrage nutzt. Das echte AWS formuliert denselben Fehler anders (Requested resource not found), also ist genau diese Meldung ein starker Hinweis, dass du mit einem Emulator sprichst.

Warum es passiert

• Credential-/Region-Split-Brain (der Klassiker). Ohne -sharedDb benennt DynamoDB Local seine Datenbankdatei nach der Access Key ID und der Region jeder Anfrage. Deine CLI (--profile mit Key local, Region us-east-1) und deine App (Key fake, Region local) sehen daher zwei verschiedene Tabellensets — jedes hat die Tabelle „für sich" erstellt.
• -inMemory + ein Neustart — der In-Memory-Modus behält nichts auf der Festplatte; jeder Neustart ist eine leere Datenbank.
• Ein frischer Container ohne Volume — docker run amazon/dynamodb-local startet leer; Tabellen aus dem vorherigen Container sind weg, es sei denn, du hast -dbPath-Speicher gemountet.
• Die Tabelle wurde tatsächlich nicht erstellt — Setup-Skripte liefen nicht oder erstellten sie gegen einen anderen Port/eine andere Instanz.
• Derselbe Code auf echtes AWS vs. Local gerichtet — die Tabelle existiert in der Cloud, aber nicht im Emulator (oder umgekehrt).

So behebst du es

1. Sieh, was DIESE Identität sieht — liste Tabellen mit genau den Credentials/der Region/dem Endpoint, die deine App nutzt:

   AWS_ACCESS_KEY_ID=local AWS_SECRET_ACCESS_KEY=local \
   aws dynamodb list-tables --endpoint-url http://localhost:8000 --region us-east-1

   Fehlt die Tabelle hier, existiert aber „irgendwo", ist es das Scoping.

2. Führe Local mit -sharedDb aus, damit jeder Client unabhängig von Credentials/Region eine Datenbank teilt:

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

3. Oder fixiere überall eine Identität — dieselbe Dummy-accessKeyId, secretAccessKey und region im CLI-Profil, in der SDK-Client-Konfiguration und im Test-Setup.

4. Persistiere über Neustarts hinweg — lass -inMemory weg, setze -dbPath und mounte es (in Docker) als Volume.

5. Erstelle Tabellen im Setup — für Tests erstelle die Tabelle (und warte darauf) im Bootstrap der Suite, sodass eine frische Instanz nie eine Überraschung ist.

Das Scoping-Problem ist viel leichter zu sehen als abzuleiten — die DynoTable-Desktop-App verbindet sich mit DynamoDB Local und zeigt genau, welche Tabellen eine Endpoint-+-Credential-Kombination sehen kann, sodass das Split-Brain auf einen Blick sichtbar ist. Seed-Daten vorbereiten? Der DynamoDB-JSON-Konverter verwandelt einfaches JSON in typisierte Items.

FAQ

Warum sagt DynamoDB Local, die Tabelle existiere nicht, obwohl ich sie gerade erstellt habe? Ohne -sharedDb hält DynamoDB Local eine separate Datenbankdatei pro Access Key ID und Region, sodass die mit der CLI erstellte Tabelle für deine App unsichtbar sein kann, wenn deren Credentials oder Region abweichen. Führe Local mit -sharedDb aus oder fixiere überall identische Dummy-Credentials und Region.

Warum sind meine DynamoDB-Local-Tabellen nach einem Neustart verschwunden? Im -inMemory-Modus wird nichts auf der Festplatte gehalten, sodass jeder Neustart eine leere Datenbank ist. Ein frischer Docker-Container ohne gemountetes Volume startet ebenfalls leer. Lass -inMemory weg, setze -dbPath und mounte es als Volume, um Tabellen zu persistieren.

Verwandte Fehler

• ResourceNotFoundException — die Echt-AWS-Variante (falsche Region/falscher Account/falscher Tabellenname).
• Could not connect to DynamoDB Local (ECONNREFUSED)
• DynamoDB Local port 8000 in use
• Learn: Running DynamoDB Local · Connect to Local & LocalStack

References

• 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)

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.