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

TL;DR — Esta es la redacción de DynamoDB Local para ResourceNotFoundException, y la trampa es que "non-existent" está acotado al fichero de base de datos que esta instancia abrió para tu clave de acceso + región actuales. Sin -sharedDb, Local mantiene un conjunto de tablas separado por combinación de credenciales/región — así que la tabla que creaste con la CLI puede ser invisible para tu aplicación. Ejecuta Local con -sharedDb (o fija credenciales dummy + región idénticas en todas partes), y recuerda que -inMemory arranca vacío en cada reinicio.

Qué significa

ResourceNotFoundException: Cannot do operations on a non-existent table

Tu petición llegó a un DynamoDB Local en ejecución, que buscó la tabla y no la encontró — en la base de datos que está usando para la identidad de tu petición. AWS real redacta el mismo fallo de otra forma (Requested resource not found), así que este mensaje exacto es una pista fuerte de que estás hablando con un emulador.

Por qué ocurre

• Cerebro dividido de credencial/región (el clásico). Sin -sharedDb, DynamoDB Local nombra su fichero de base de datos según el access key ID y la región de cada petición. Tu CLI (--profile con clave local, región us-east-1) y tu aplicación (clave fake, región local) ven por tanto dos conjuntos de tablas distintos — cada uno creó la tabla "para sí mismo".
• -inMemory + un reinicio — el modo en memoria no guarda nada en disco; cada reinicio es una base de datos en blanco.
• Un contenedor nuevo sin volumen — docker run amazon/dynamodb-local arranca vacío; las tablas del contenedor anterior desaparecen salvo que montaras almacenamiento con -dbPath.
• La tabla realmente no se creó — los scripts de configuración no se ejecutaron, o la crearon contra otro puerto/instancia.
• El mismo código apuntando a AWS real vs Local — la tabla existe en la nube pero no en el emulador (o viceversa).

Cómo solucionarlo

1. Ve lo que ESTA identidad ve — lista las tablas exactamente con las credenciales/región/endpoint que usa tu aplicación:

   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 tabla falta aquí pero existe "en algún sitio", es el acotamiento.

2. Ejecuta Local con -sharedDb para que cada cliente comparta una base de datos independientemente de las credenciales/región:

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

3. O fija una identidad en todas partes — el mismo accessKeyId, secretAccessKey y region dummy en el perfil de la CLI, la configuración del cliente del SDK y la configuración de tests.

4. Persiste entre reinicios — quita -inMemory, define -dbPath y (en Docker) móntalo como volumen.

5. Crea las tablas en la configuración — para los tests, crea la tabla (y espera a ella) en el bootstrap de la suite para que una instancia nueva nunca sea una sorpresa.

El problema de acotamiento es mucho más fácil de ver que de deducir — la aplicación de escritorio DynoTable se conecta a DynamoDB Local y muestra exactamente qué tablas puede ver una combinación de endpoint + credencial, así que el cerebro dividido se hace visible de un vistazo. ¿Preparando datos de semilla? El conversor de DynamoDB JSON convierte JSON plano en items tipados.

FAQ

¿Por qué DynamoDB Local dice que la tabla no existe cuando acabo de crearla? Sin -sharedDb, DynamoDB Local mantiene un fichero de base de datos separado por access key ID y región, así que la tabla que creaste con la CLI puede ser invisible para tu aplicación si sus credenciales o su región difieren. Ejecuta Local con -sharedDb o fija credenciales dummy y región idénticas en todas partes.

¿Por qué desaparecieron mis tablas de DynamoDB Local tras un reinicio? En modo -inMemory no se guarda nada en disco, así que cada reinicio es una base de datos en blanco. Un contenedor de Docker nuevo sin un volumen montado también arranca vacío. Quita -inMemory, define -dbPath y móntalo como volumen para persistir las tablas.

Errores relacionados

• ResourceNotFoundException — la variante de AWS real (región/cuenta/nombre de tabla equivocados).
• Could not connect to DynamoDB Local (ECONNREFUSED)
• DynamoDB Local port 8000 in use
• Aprende: Ejecutar DynamoDB Local · Conectar a Local y LocalStack

Referencias

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

Verificado por última vez el 2026-07-13 contra la documentación oficial de AWS enlazada arriba.