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

In breve — Questa è la formulazione di ResourceNotFoundException di DynamoDB Local, e la trappola è che "non-existent" è limitato al file di database che questa istanza ha aperto per la tua attuale access key + region. Senza -sharedDb, Local mantiene un set di tabelle separato per ogni combinazione credenziali/region — quindi la tabella che hai creato con la CLI può essere invisibile alla tua applicazione. Esegui Local con -sharedDb (o fissa le stesse credenziali fittizie + region ovunque), e ricorda che -inMemory riparte vuoto a ogni riavvio.

Cosa significa

ResourceNotFoundException: Cannot do operations on a non-existent table

La tua richiesta ha raggiunto un DynamoDB Local in esecuzione, che ha cercato la tabella e non l'ha trovata — nel database che sta usando per l'identità della tua richiesta. AWS reale formula lo stesso fallimento in modo diverso (Requested resource not found), quindi questo messaggio esatto è un forte indizio che stai comunicando con un emulatore.

Perché accade

• Split-brain credenziali/region (il classico). Senza -sharedDb, DynamoDB Local nomina il suo file di database in base all'access key ID e alla region di ogni richiesta. La tua CLI (--profile con chiave local, region us-east-1) e la tua applicazione (chiave fake, region local) vedono quindi due set di tabelle diversi — ciascuno ha creato la tabella "per sé".
• -inMemory + un riavvio — la modalità in memoria non conserva nulla su disco; ogni riavvio è un database vuoto.
• Un container nuovo senza volume — docker run amazon/dynamodb-local parte vuoto; le tabelle del container precedente sono perse a meno che tu non abbia montato uno storage -dbPath.
• La tabella non è stata davvero creata — gli script di setup non sono stati eseguiti, o l'hanno creata su una porta/istanza diversa.
• Lo stesso codice puntato su AWS reale vs Local — la tabella esiste nel cloud ma non nell'emulatore (o viceversa).

Come correggerlo

1. Guarda cosa vede QUESTA identità — elenca le tabelle con esattamente le credenziali/region/endpoint che usa la tua applicazione:

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

   Se la tabella manca qui ma esiste "da qualche parte", è lo scoping.

2. Esegui Local con -sharedDb così ogni client condivide un solo database indipendentemente da credenziali/region:

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

3. Oppure fissa un'unica identità ovunque — gli stessi accessKeyId, secretAccessKey e region fittizi nel profilo CLI, nella config del client SDK e nel setup dei test.

4. Persisti tra i riavvii — rimuovi -inMemory, imposta -dbPath e (in Docker) montalo come volume.

5. Crea le tabelle nel setup — per i test, crea la tabella (e attendila) nel bootstrap della suite così un'istanza nuova non è mai una sorpresa.

Il problema di scoping è molto più facile da vedere che da dedurre — l'app desktop DynoTable si connette a DynamoDB Local e mostra esattamente quali tabelle una combinazione endpoint + credenziali può vedere, così lo split-brain è visibile a colpo d'occhio. Stai preparando dati di seed? Il convertitore DynamoDB JSON trasforma il JSON semplice in Item tipizzati.

FAQ

Perché DynamoDB Local dice che la tabella non esiste quando l'ho appena creata? Senza -sharedDb, DynamoDB Local mantiene un file di database separato per ogni access key ID e region, quindi la tabella che hai creato con la CLI può essere invisibile alla tua applicazione se le loro credenziali o region differiscono. Esegui Local con -sharedDb o fissa le stesse credenziali fittizie e region ovunque.

Perché le mie tabelle DynamoDB Local sono sparite dopo un riavvio? In modalità -inMemory nulla viene conservato su disco, quindi ogni riavvio è un database vuoto. Anche un container Docker nuovo senza un volume montato parte vuoto. Rimuovi -inMemory, imposta -dbPath e montalo come volume per persistere le tabelle.

Errori correlati

• ResourceNotFoundException — la variante AWS-reale (region/account/nome tabella errati).
• Could not connect to DynamoDB Local (ECONNREFUSED)
• DynamoDB Local port 8000 in use
• Impara: 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)

Ultima verifica 2026-07-13 rispetto alla documentazione ufficiale AWS collegata sopra.