Leituras consistentes não são suportadas em índices secundários globais

TL;DR — Você define ConsistentRead: true em um Query ou Scan que tem como alvo um índice secundário global. Os GSIs replicam da tabela base de forma assíncrona e servem apenas leituras eventualmente consistentes – o sinalizador é um erro grave, não uma preferência. Elimine o sinalizador ou, se você realmente precisar de consistência de leitura após gravação, leia a tabela base (ou crie a chave em um LSI).

O que significa

ValidationException: Consistent reads are not supported on global secondary indexes

Um GSI é fisicamente sua própria estrutura de índice com suas próprias partições e capacidade; O DynamoDB propaga escritas da tabela base de forma assíncrona. Como um item que você acabou de escrever pode ainda não ter chegado ao índice, o DynamoDB não pode honrar uma leitura fortemente consistente contra ele - então o ConsistentRead: true combinado com um GSI IndexName é rejeitado imediatamente. A documentação do AWS é explícita: consulte um GSI com ConsistentRead definido como verdadeiro e você receberá um ValidationException.

Os índices secundários locais são diferentes: um LSI compartilha sua partição com a tabela base, portanto, ConsistentRead: true é suportado lá.

Por que isso acontece

O sinalizador foi definido globalmente — um auxiliar de consulta compartilhado ou wrapper de cliente padroniza ConsistentRead: true para cada leitura, e um caminho de chamada adiciona um IndexName apontando para um GSI.
Um LSI tornou-se um GSI — o código escrito para um índice local (onde o sinalizador é legal) foi apontado para um índice global.
Consulta de tabela base copiada e colada — uma consulta que usava legitimamente consistência forte na tabela foi reutilizada com IndexName adicionado.

Como corrigir

Remova ConsistentRead das leituras GSI (ou defina-o como false — o padrão):

await client.send(
  new QueryCommand({
    TableName: 'Orders',
    IndexName: 'status-index',
    KeyConditionExpression: '#s = :open',
    // ConsistentRead: true  ← delete this line for a GSI
    ExpressionAttributeNames: {'#s': 'status'},
    ExpressionAttributeValues: {':open': {S: 'OPEN'}}
  })
);

Precisa de leitura após gravação? Consulte a tabela base com ConsistentRead: true — possível sempre que a chave que você está buscando for a chave de partição da própria tabela.
Mesma chave de partição, ordenação diferente? Modele como um LSI (criado junto com a tabela), que suporta leituras consistentes.
Ou absorva o atraso na aplicação — a propagação para o GSI costuma ser rápida; em fluxos de UI, devolver os dados recém-gravados que você já tem é melhor do que reler o índice.
Audite os helpers de consulta compartilhados. Um ConsistentRead: true padrão em toda leitura quebra no momento em que qualquer caminho de chamada adiciona um IndexName de GSI.

Verifique no DynoTable

O DynoTable sabe quais índices são GSIs e quais são LSIs — consultas a GSI nunca enviam ConsistentRead: true. Abra uma tabela com ⌘K, escolha um índice no menu suspenso e execute a consulta sem a flag.

Quando você precisar de leitura após gravação, consulte a tabela base — o Query Builder gera os parâmetros corretos para cada alvo. Troque de perfil com ⌘P; consulte Conectar ao AWS e Instalar.

Fontes

Query — Amazon DynamoDB API Reference (verificado em 13/07/2026)
Using Global Secondary Indexes in DynamoDB (verificado em 13/07/2026)

Erros relacionados

GSI throttles the base table — o acoplamento do lado de escrita dos GSIs.
A tabela não tem o índice especificado
Não é possível atualizar um GSI enquanto ele está sendo criado
Exemplo de código: Query a GSI in Node.js — uma consulta de GSI com consistência eventual feita corretamente.
Aprenda: Why GSIs are eventually consistent · GSI vs LSI · Consistency · Índices

Referências

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