Consistent reads are not supported on global secondary indexes

TL;DR — Du hast ConsistentRead: true auf einer Query oder einem Scan gesetzt, die/der einen globalen Secondary Index anvisiert. GSIs replizieren asynchron von der Basistabelle und bedienen nur letztendlich konsistente Reads — das Flag ist ein harter Fehler, keine Präferenz. Lass das Flag weg, oder wenn du wirklich Read-after-Write-Konsistenz brauchst, lies die Basistabelle (oder modelliere den Schlüssel in einen LSI).

Was es bedeutet

ValidationException: Consistent reads are not supported on global secondary indexes

Ein GSI ist physisch seine eigene Indexstruktur mit eigenen Partitionen und eigener Kapazität; DynamoDB propagiert Basistabellen-Writes asynchron hinein. Weil ein gerade geschriebenes Item möglicherweise noch nicht im Index angekommen ist, kann DynamoDB einen stark konsistenten Read dagegen nicht bedienen — also wird ConsistentRead: true in Kombination mit einem GSI-IndexName schlicht abgewiesen. Die AWS-Dokumentation ist eindeutig: Fragst du einen GSI mit auf true gesetztem ConsistentRead ab, erhältst du eine ValidationException.

Local Secondary Indexes sind anders: Ein LSI teilt seine Partition mit der Basistabelle, sodass ConsistentRead: true dort unterstützt wird.

Warum es passiert

• Das Flag wurde global gesetzt — ein gemeinsamer Query-Helper oder Client-Wrapper setzt ConsistentRead: true als Default für jeden Read, und ein Aufrufpfad fügt einen IndexName hinzu, der auf einen GSI zeigt.
• Ein LSI wurde zu einem GSI — Code, der für einen lokalen Index geschrieben wurde (wo das Flag legal ist), wurde auf einen globalen gerichtet.
• Kopierte Basistabellen-Query — eine Query, die legitim starke Konsistenz auf der Tabelle nutzte, wurde mit hinzugefügtem IndexName wiederverwendet.

So behebst du es

1. Entferne ConsistentRead aus GSI-Reads (oder setze es auf false — den 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'}}
     })
   );

2. Brauchst du Read-after-Write? Frage die Basistabelle mit ConsistentRead: true ab — möglich, wann immer der gesuchte Schlüssel der eigene Partitionsschlüssel der Tabelle ist.

3. Gleicher Partitionsschlüssel, anderer Sort? Modelliere es als LSI (bei der Tabellenerstellung angelegt), der konsistente Reads unterstützt.

4. Oder fange die Verzögerung in der Anwendung ab — GSI-Propagation ist typischerweise schnell; für UI-Abläufe schlägt es das erneute Lesen des Index, die gerade geschriebenen Daten zurückzugeben, die du bereits hast.

Die DynoTable-Desktop-App zeigt die Indizes jeder Tabelle und lässt dich sie direkt abfragen — und weil sie weiß, welcher Index global und welcher lokal ist, tritt diese Fehlerklasse schlicht nicht auf.

Verwandte Fehler

• GSI throttles the base table — die Schreib-seitige Kopplung von GSIs.
• The table does not have the specified index
• Cannot update GSI while it is being created
• Code example: Query a GSI in Node.js — eine letztendlich konsistente GSI-Query richtig gemacht.
• Learn: Why GSIs are eventually consistent · GSI vs LSI · Consistency

References

• Query — Amazon DynamoDB API Reference
• Using Global Secondary Indexes in DynamoDB — Amazon DynamoDB Developer Guide
• Constraints in Amazon DynamoDB — Amazon DynamoDB Developer Guide

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.