Le letture coerenti non sono supportate sugli indici secondari globali

TL;DR — Imposta "ConsistentRead: true" su una "Query" o una "Scansione" che ha come target un indice secondario globale. I GSI si replicano dalla tabella di base in modo asincrono e servono solo letture eventualmente coerenti: il flag è un errore grave, non una preferenza. Rilascia il flag o, se hai davvero bisogno di coerenza lettura dopo scrittura, leggi la tabella di base (o progetta la chiave in un LSI).

Cosa significa

ValidationException: Consistent reads are not supported on global secondary indexes

A GSI è fisicamente la propria struttura di indice con le proprie partizioni e capacità; DynamoDB propaga le scritture della tabella base in modo asincrono. Poiché un elemento che hai appena scritto potrebbe non essere ancora arrivato nell'indice, DynamoDB non può onorare una lettura fortemente coerente rispetto ad esso, quindi ConsistentRead: true combinato con un GSI IndexName viene rifiutato completamente. La documentazione AWS è esplicita: esegui una query su GSI con ConsistentRead impostato su true e ricevi una ValidationException.

Gli indici secondari locali sono diversi: un LSI condivide la sua partizione con la tabella di base, quindi ConsistentRead: true è supportato lì.

Perché succede

Il flag è stato impostato a livello globale: un helper di query condiviso o un wrapper client imposta come predefinito ConsistentRead: true per ogni lettura e un percorso di chiamata aggiunge un IndexName che punta a GSI.
Un LSI è diventato un GSI — il codice scritto per un indice locale (dove la bandiera è legale) è stato puntato su uno globale.
Query sulla tabella di base copiata e incollata: una query che utilizzava legittimamente una forte coerenza sulla tabella è stata riutilizzata con l'aggiunta di "IndexName".

Come risolverlo

Rimuovi ConsistentRead da GSI letture (o impostalo su false — il valore predefinito):

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'}}
  })
);

Hai bisogno di lettura dopo scrittura? Interroga la tabella di base con ConsistentRead: true: è possibile ogni volta che la chiave che stai cercando è la chiave di partizione della tabella.
Stessa chiave di partizione, ordinamento diverso? Modellalo come LSI (creato durante la creazione della tabella), che supporta letture coerenti.
Oppure assorbi il ritardo nell'applicazione — La propagazione GSI è in genere veloce; per i flussi dell'interfaccia utente, restituire i dati appena scritti che hai già batte la rilettura dell'indice.
Controlla gli helper delle query condivise. Un ConsistentRead: true predefinito su ogni lettura si interrompe nel momento in cui qualsiasi percorso di chiamata aggiunge un GSI IndexName.

Verificalo in DynoTable

DynoTable sa quali indici sono GSI e LSI — GSI le query non inviano mai ConsistentRead: true. Apri una tabella con ⌘K, seleziona un indice dal menu a discesa ed esegui la query senza il flag.

Quando è necessaria la lettura dopo la scrittura, interroga invece la tabella di base: il Query Builder genera i parametri corretti per destinazione. Cambia profilo con ⌘P; vedere Connetti a AWS e Installa.

Fonti

Query: riferimento Amazon DynamoDB API (verificato il 13-07-2026)
Utilizzo degli indici secondari globali in DynamoDB (verificato il 13-07-2026)

Errori correlati

GSI limita la tabella di base — l'accoppiamento lato scrittura dei GSI.
La tabella non ha l'indice specificato
Impossibile aggiornare GSI durante la creazione
Esempio di codice: Query a GSI in Node.js — una query GSI finalmente coerente eseguita correttamente.
Impara: Perché i GSI alla fine sono coerenti · GSI vs LSI · Coerenza · Panoramica degli indici

Riferimenti

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