Consistent reads are not supported on global secondary indexes

TL;DR — Você definiu ConsistentRead: true em uma Query ou Scan que mira um índice secundário global. GSIs replicam da tabela base de forma assíncrona e só servem leituras com consistência eventual — a flag é um erro fatal, não uma preferência. Remova a flag, ou se você realmente precisa de consistência read-after-write, leia a tabela base (ou projete 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 as escritas da tabela base para dentro dele 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 ConsistentRead: true combinado com um IndexName de GSI é rejeitado de imediato. A documentação da AWS é explícita: consulte um GSI com ConsistentRead definido como true e você recebe um ValidationException.

Índices secundários locais são diferentes: um LSI compartilha sua partição com a tabela base, então ConsistentRead: true é suportado ali.

Por que acontece

A flag foi definida globalmente — um helper de consulta compartilhado ou wrapper de cliente define ConsistentRead: true por padrão para toda leitura, e um caminho de chamada adiciona um IndexName apontando para um GSI.
Um LSI virou um GSI — código escrito para um índice local (onde a flag é legal) foi apontado para um global.
Consulta de tabela base copiada e colada — uma consulta que legitimamente usava consistência forte na tabela foi reutilizada com IndexName adicionado.

Como corrigir

Remova ConsistentRead das leituras de 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 read-after-write? Consulte a tabela base com ConsistentRead: true — possível sempre que a chave que você procura é a própria chave de partição da tabela.
Mesma chave de partição, ordenação diferente? Modele-a como um LSI (criado na criação da tabela), que suporta leituras consistentes.
Ou absorva o atraso na aplicação — a propagação do GSI é normalmente rápida; para fluxos de UI, retornar os dados recém-escritos que você já tem é melhor do que reler o índice.

O app desktop DynoTable mostra os índices de cada tabela e permite consultá-los diretamente — e porque ele sabe qual índice é global e qual é local, essa classe de erro simplesmente não aparece.

Erros relacionados

GSI throttles the base table — o acoplamento do lado de escrita dos GSIs.
The table does not have the specified index
Cannot update GSI while it is being created
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

Referências

Verificado pela última vez em 2026-07-13 contra a documentação oficial da AWS vinculada acima.