Consistent reads are not supported on global secondary indexes

TL;DR — Anda mengatur ConsistentRead: true pada Query atau Scan yang menargetkan global secondary index. GSI mereplikasi dari tabel dasar secara asinkron dan hanya melayani eventually consistent reads — flag ini adalah kesalahan keras, bukan preferensi. Hapus flag, atau jika Anda benar-benar butuh read-after-write consistency, baca tabel dasar (atau desain kuncinya ke dalam LSI).

Apa artinya

ValidationException: Consistent reads are not supported on global secondary indexes

GSI secara fisik adalah struktur index-nya sendiri dengan partisi dan kapasitasnya sendiri; DynamoDB menyebarkan tulisan tabel dasar ke dalamnya secara asinkron. Karena item yang baru saja Anda tulis mungkin belum tiba di index, DynamoDB tidak dapat menghormati strongly consistent read terhadapnya — jadi ConsistentRead: true yang dikombinasikan dengan IndexName GSI ditolak langsung. Dokumentasi AWS eksplisit: kueri GSI dengan ConsistentRead diatur true dan Anda menerima ValidationException.

Local secondary index berbeda: sebuah LSI berbagi partisinya dengan tabel dasar, jadi ConsistentRead: true didukung di sana.

Mengapa terjadi

Flag diatur secara global — pembantu kueri bersama atau pembungkus klien mengatur default ConsistentRead: true untuk setiap baca, dan satu jalur panggilan menambahkan IndexName yang menunjuk ke GSI.
LSI menjadi GSI — kode yang ditulis untuk index lokal (di mana flag legal) diarahkan ke index global.
Kueri tabel dasar yang disalin-tempel — kueri yang secara sah menggunakan strong consistency pada tabel digunakan ulang dengan IndexName ditambahkan.

Cara memperbaikinya

Hapus ConsistentRead dari baca GSI (atau atur ke false — default-nya):

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

Butuh read-after-write? Kueri tabel dasar dengan ConsistentRead: true — mungkin kapan pun kunci yang Anda cari adalah partition key milik tabel itu sendiri.
Partition key sama, sort berbeda? Modelkan sebagai LSI (dibuat saat pembuatan tabel), yang mendukung consistent reads.
Atau serap keterlambatan dalam aplikasi — propagasi GSI biasanya cepat; untuk alur UI, mengembalikan data yang baru ditulis yang sudah Anda miliki mengalahkan membaca ulang index.

Aplikasi desktop DynoTable menunjukkan index setiap tabel dan memungkinkan Anda mengkuerinya langsung — dan karena ia tahu index mana yang global dan mana yang lokal, kelas kesalahan ini tidak muncul sama sekali.

Kesalahan terkait

GSI throttles the base table — penggabungan sisi tulis GSI.
The table does not have the specified index
Cannot update GSI while it is being created
Contoh kode: Query a GSI in Node.js — kueri GSI eventually-consistent yang dilakukan dengan benar.
Pelajari: Why GSIs are eventually consistent · GSI vs LSI · Consistency

References

Terakhir diverifikasi 2026-07-13 terhadap dokumentasi resmi AWS yang ditautkan di atas.