Read timeout without replica abort in Cassandra coordinator

Direct answers

1. No. A coordinator timeout means the coordinator stopped waiting for acknowledgments; it does not mean replicas aborted the mutation. A replica may have applied the write before the timeout fired.
2. No. The native protocol has no distributed cancellation token, and the driver retry policy cannot observe replica state. It cannot distinguish an unapplied timed-out write from an applied one.
3. Not by itself. Declaring a statement idempotent makes a retry safe only if the write is genuinely idempotent and the Cassandra version supports the idempotent flag. Support exists in 3.x and later; releases before 3.0 do not have it.

Confirmed facts and assumptions

Confirmed: when the coordinator timeout expires, it replies to the client without sending an abort to replicas. The mutation may already be in flight or applied.

Assumed: the target cluster runs Cassandra 3.x or later. This assumption changes the recommendation because pre-3.0 releases lack the idempotent write flag. Confirm the version before enabling retries.

Steps for this case

1. Run nodetool version on the cluster to confirm the Cassandra version.
2. Mark the statement idempotent in the driver only when the write is naturally idempotent, such as upserting the same column value. Do not mark counters, increments, or other non-idempotent writes as idempotent.
3. Configure the driver retry policy to retry idempotent statements on timeout. Do not retry non-idempotent statements after a coordinator timeout.
4. For critical data that cannot be safely retried, use a lightweight transaction and handle the conditional result explicitly.

Missing diagnostic detail

What is the exact Cassandra version? If it is earlier than 3.0, do not rely on driver-level idempotent retries; redesign the write path or upgrade first.

Verification

On a test cluster, enable DEBUG logging for org.apache.cassandra.net.Message and observe coordinator timeout events. Use nodetool tpstats or JMX getStorageProxy to check replica apply latency after a simulated timeout. These are read-only verification commands.