Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Bug] Cassandra: ConsistentRead true is served at ONE against writes committed at ONE

オープン
  • 何か問題がありますか？
#560 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@LeeroyHannigan がすでに取り組んでいます。

2026年10月25日 から。

  • #591 @LeeroyHannigan による — オープン

評価

この issue はまだ評価されていません。

説明

backend:cassandra bug

Describe the bug

The Cassandra backend serves a ConsistentRead: true GetItem, Query or Scan at the driver's default consistency level, ONE, and commits its base-row writes at ONE as well. With the default keyspace replication factor of 3, one replica acknowledges the write and one replica answers the read, so a read can return the item as it was before a PutItem that the client already saw succeed. The service guarantees that a strongly consistent read reflects every write acknowledged before it started.

The statements involved, read from the source at main (744ea291):

  • Reads: get_item_impl, query_impl and scan_impl under crates/storage-cassandra/src/data/ issue their statements with no consistency level, so the driver default applies. cassandra_protocol 4.0.1 marks Consistency::One as the default, and crates/storage-cassandra/src/cassandra_util.rs says so of query_rows ("uses the driver's default consistency, which is ONE").
  • Writes acknowledged at ONE: the OCC write lightweight transaction (data/update_item.rs, occ_write), put_item_if_not_exists (data/put_get_item.rs), the plain DELETE for a table with no index, stream or TTL (data/delete_item.rs), and the TransactWriteItems commit statement (data/transactions.rs). For a lightweight transaction the statement's consistency is the commit consistency, so the commit is acknowledged by one replica.
  • Writes at LOCAL_QUORUM: the conditional delete (query_lwt), the secondary-effects batches and the TTL-claim path.

get_item_quorum in data/put_get_item.rs exists for the TTL worker and reads at LOCAL_QUORUM; the request path does not use it.

Since #559 the flag reaches the backend as ReadOptions::consistent_read, so the routing has somewhere to hang; the backend does not act on it yet.

To Reproduce

  1. Start ExtendDB on the Cassandra backend against a three-node cluster (or a single node with the keyspace replication factor left at the default 3 and nodetool used to pause one node).
  2. PutItem an item; on success, GetItem the same key with ConsistentRead: true in a tight loop.
  3. With one replica lagging (the paused node resumed, or under write load), observe a GetItem that returns the previous item or no item.

A single-node cluster with replication factor 1 does not show it: one replica holds every write.

Expected behavior

A ConsistentRead: true read reflects every write acknowledged before it started. On Cassandra that needs read and write levels that intersect within the datacenter: base-row writes acknowledged at LOCAL_QUORUM (the lightweight transactions at commit consistency LOCAL_QUORUM, as query_lwt already sets; the plain DELETE; the transaction commit statements) and true reads at LOCAL_QUORUM. false reads can stay at LOCAL_ONE.

Actual behavior

Reads and base-row writes run at ONE. Two replicas plus one replica is three, which does not exceed the replication factor of three, so the read set and the write set can be disjoint.

Environment

  • ExtendDB version: main at 744ea291 (0.1.14), read from the source
  • Operating system: any
  • Deployment method: source

Additional context

Raising the read level alone (a LOCAL_QUORUM or LOCAL_SERIAL read for true) does not close the gap while the writes commit at ONE: a non-serial quorum read does not consult Paxos state, and the plain DELETE and the batches are not Paxos writes. The write side has to move with it, which changes write latency for every base-row write; that is the trade this issue asks the backend owners to make.

ADR-0024 (in #559) names this gap under Consequences. The doc comment on CassandraEngine::get_item on that branch states the current levels.

Checklist

  • I have searched existing issues for duplicates
  • I have included the ExtendDB version and environment details
  • I can reproduce this with the latest release (derived from the source and the driver default; not reproduced on a cluster)
主要言語
Rust
スター
517
フォーク
60
平均マージ
2日 23時間
マージ済み PR（30日）
25

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ExtendDB/extenddb のほかの issue

ExtendDB/extenddb の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。