Consistent reads are not supported on global secondary indexes

TL;DR — Du hast ConsistentRead: true auf einer Query oder einem Scan gesetzt, die auf einen Global Secondary Index zielen. GSIs replizieren asynchron von der Basistabelle und bedienen ausschließlich eventually consistent Reads — das Flag ist ein harter Fehler, keine Präferenz. Lass es weg, oder lies die Basistabelle, wenn du wirklich Read-after-Write-Konsistenz brauchst (oder plane den Schlüssel in einen LSI ein).

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

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

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.
Gleicher Partitionsschlüssel, anderer Sort? Modelliere es als LSI (bei der Tabellenerstellung angelegt), der konsistente Reads unterstützt.
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.

In DynoTable checken

DynoTable weiß, welche indexes are GSIs vs LSIs — GSI-Queries senden nie ConsistentRead: true. Öffne eine Tabelle mit ⌘K, wähle einen Index aus dem Dropdown, und führe die Query ohne Flag aus.

Wenn du need read-after-write, query the base table instead — the Query Builder generiert die korrekten Parameter pro Target. Wechsle Profile mit ⌘P; see Mit AWS verbinden and Installation.

Quellen

Query — Amazon DynamoDB API Reference (verifiziert 2026-07-13)
Using Global Secondary Indexes in DynamoDB (verifiziert 2026-07-13)

Referenzen

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