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

TL;DR — Das ist DynamoDB Locals Formulierung von ResourceNotFoundException, und die Falle ist: „non-existent" bezieht sich auf die Datenbankdatei, die diese Instanz für deinen aktuellen Access Key + deine Region geöffnet hat. Ohne -sharedDb hält Local pro Credentials-/Region-Kombination einen eigenen Tabellensatz — die Tabelle, die du mit der CLI angelegt hast, kann für deine App also unsichtbar sein. Starte Local mit -sharedDb (oder fixiere überall identische Dummy-Credentials + Region), und denk daran, dass -inMemory bei jedem Neustart leer beginnt.

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

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.

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

Oder fixiere überall eine Identität — dieselbe Dummy-accessKeyId, secretAccessKey und region im CLI-Profil, in der SDK-Client-Konfiguration und im Test-Setup.
Persistiere über Neustarts hinweg — lass -inMemory weg, setze -dbPath und mounte es (in Docker) als Volume.
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.

DynoTable + Local

Das Scoping-Problem ist viel leichter zu sehen als zu erschließen. DynoTable installieren, ein Local-Profil hinzufügen (Einstellungen → Profile → Profil hinzufügen) mit dem Endpunkt http://localhost:8000 und demselben Access Key + derselben Region, die deine CLI nutzt, und dann die Tabellenliste in der Seitenleiste mit aws dynamodb list-tables --endpoint-url http://localhost:8000 vergleichen. Nicht passende Anmeldedaten verteilen Tabellen auf getrennte myaccesskeyid_region.db-Dateien (DynamoDB Local betreiben). Nach einem -inMemory-Neustart lädst du Fixtures mit dem DynamoDB-JSON-Konverter wieder ein.

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.

Quellen

DynamoDB local usage notes — Amazon DynamoDB Developer Guide (verified 2026-07-13 — -sharedDb, -inMemory, per-credential DB files)
Deploying DynamoDB locally on your computer — Amazon DynamoDB Developer Guide (verified 2026-07-13)
amazon/dynamodb-local — Docker Hub (verified 2026-07-13)