Consistent reads are not supported on global secondary indexes

In breve — Hai impostato ConsistentRead: true su una Query o Scan che punta a un indice secondario globale. I GSI si replicano dalla tabella base in modo asincrono e servono solo letture a coerenza eventuale — il flag è un errore vero e proprio, non una preferenza. Rimuovi il flag, oppure, se ti serve davvero la coerenza read-after-write, leggi la tabella base (o inserisci la chiave in un LSI).

Cosa significa

ValidationException: Consistent reads are not supported on global secondary indexes

Un GSI è fisicamente una propria struttura di indice con proprie partizioni e capacità; DynamoDB propaga le scritture della tabella base al suo interno in modo asincrono. Poiché un Item che hai appena scritto potrebbe non essere ancora arrivato nell'indice, DynamoDB non può onorare una lettura a coerenza forte su di esso — quindi ConsistentRead: true combinato con un IndexName di GSI viene rifiutato senza mezzi termini. La documentazione AWS è esplicita: interroga un GSI con ConsistentRead impostato a true e ricevi una ValidationException.

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

Perché accade

Il flag è stato impostato globalmente — un helper di query condiviso o un wrapper del client imposta ConsistentRead: true come default per ogni lettura, e un percorso di chiamata aggiunge un IndexName che punta a un GSI.
Un LSI è diventato un GSI — codice scritto per un indice locale (dove il flag è legale) è stato puntato su uno globale.
Query sulla tabella base copiata-incollata — una query che usava legittimamente la coerenza forte sulla tabella è stata riutilizzata aggiungendo IndexName.

Come correggerlo

Rimuovi ConsistentRead dalle letture sui GSI (o impostalo a false — il default):

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

Serve read-after-write? Interroga la tabella base con ConsistentRead: true — possibile ogni volta che la chiave che stai cercando è la partition key della tabella stessa.
Stessa partition key, sort diversa? Modellala come un LSI (creato alla creazione della tabella), che supporta le letture coerenti.
Oppure assorbi il ritardo nell'applicazione — la propagazione dei GSI è tipicamente rapida; per i flussi UI, restituire i dati appena scritti che già possiedi è meglio che rileggere l'indice.

L'app desktop DynoTable mostra gli indici di ogni tabella e ti permette di interrogarli direttamente — e poiché sa quale indice è globale e quale locale, questa classe di errori semplicemente non si presenta.

Errori correlati

GSI throttles the base table — l'accoppiamento lato scrittura dei GSI.
The table does not have the specified index
Cannot update GSI while it is being created
Esempio di codice: Query a GSI in Node.js — una query su GSI a coerenza eventuale fatta bene.
Impara: Why GSIs are eventually consistent · GSI vs LSI · Consistency

References

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