ValidationException: Inesperado da fonte

TL;DR — O nome da tabela em sua cláusula PartiQL FROM contém caracteres que o analisador não aceitará vazios — geralmente um travessão. Coloque o nome entre aspas duplas (SELECT * FROM "my-table"). Aspas simples não funcionam: em PartiQL elas significam uma string literal, não um identificador.

O que significa

ValidationException: Unexpected from source

O analisador PartiQL lê FROM my-table como o identificador my seguido por tokens inesperados — o traço não é válido dentro de um identificador simples. Os nomes de tabelas DynamoDB podem conter legalmente -, . e _, portanto, um nome de tabela perfeitamente válido ainda pode não ser analisável em PartiQL até que seja citado. O mesmo se aplica a nomes que colidem com palavras-chave PartiQL.

Por que isso acontece

O nome da tabela contém um traço ou ponto — users-prod, app.events. Identificadores simples não podem carregá-los.
Nomes de tabelas gerados pela estrutura — ferramentas que colocam um sufixo em um ambiente ou estágio no nome da tabela (por exemplo, Todo-dev) é a forma clássica de um travessão entrar sem que você o escolha.
Consultando um índice sem aspas — o formulário "table"."index" precisa de aspas duplas em ambas as partes.
Aspas simples em vez de duplas — FROM 'my-table' também falha: aspas simples denotam uma string literal em PartiQL, não um nome.

Como corrigir

Coloque aspas duplas no nome da tabela:
```
SELECT * FROM "users-prod" WHERE pk = 'USER#42'
```
Coloque aspas duplas nas duas partes ao consultar um índice:
```
SELECT * FROM "users-prod"."email-index" WHERE email = 'ada@example.com'
```
Mantenha aspas simples apenas para valores de string — nomes entre aspas duplas, valores entre aspas simples. Misturá-los produz exatamente esta classe de erro de análise.
Citar defensivamente em instruções geradas — se seu código interpolar nomes de tabelas em PartiQL, sempre emita-os entre aspas duplas; é válido mesmo quando o nome não precisa estritamente dele.
Prefira a consulta nativa quando possível. Uma solicitação Query/Scan contorna inteiramente as regras do identificador PartiQL para leituras simples.

Execute no DynoTable

O editor PartiQL do DynoTable coloca aspas duplas em nomes de tabelas e índices automaticamente - execute SELECT * FROM "my-table" com diagnósticos embutidos antes de colar a instrução no código SDK. Abra a tabela com ⌘K para confirmar o nome exato da tabela (incluindo travessões) na barra lateral.

Quando a análise do PartiQL continuar falhando, alterne para o Query Builder para obter a solicitação nativa equivalente. A troca de perfil (⌘P) e Test Connection em Configurações → Perfis mantêm a instrução apontada para a tabela certa. Consulte Conectar ao AWS e Instalar.

Fontes

Instruções de seleção PartiQL para DynamoDB (verificado em 13/07/2026)
Tipos de dados e regras de nomenclatura suportados (verificado em 13/07/2026)

Reproduza

Uma instrução PartiQL cuja origem FROM não é um nome de tabela. O analisador o rejeita antes mesmo de procurar uma tabela, então isso se reproduz em qualquer endpoint:

await client.send(new ExecuteStatementCommand({Statement: 'SELECT * FROM 123'}));

Saída real:

ValidationException: Unexpected from source
HTTP 400

Compare-o com um nome sem aspas, mas válido: SELECT * FROM repro analisa bem e falha posteriormente com ResourceNotFoundException se tal tabela não existir. Unexpected from source é estritamente uma falha de análise, então leia-o como um sinal de sintaxe, não como um sinal de tabela ausente.

Erros relacionados

DuplicateItemException — PartiQL INSERT em uma chave existente.
ValidationException — a classe de exceção pai.
Aprenda: exemplos PartiQL · SQL para DynamoDB

Referências

Última verificação em 13/07/2026 em relação à documentação oficial do AWS vinculada acima.

Reproduzido em 26/07/2026 em DynamoDB Local 2.x com AWS SDK para JavaScript v3.1095.0 - a saída acima é literal.