{"record":{"id":"d5f415827321ff62","repo":"apache/cassandra","slug":"operation-timed-out","errorCode":null,"errorMessage":"Operation timed out","messagePattern":"Operation timed out","errorType":"exception","errorClass":"Paxos.MaybeFailure","httpStatus":null,"severity":"error","filePath":"src/java/org/apache/cassandra/service/paxos/Paxos.java","lineNumber":955,"sourceCode":"                    default: throw new IllegalStateException();\n                    case MAYBE_FAILURE:\n                        throw propose.maybeFailure().markAndThrowAsTimeoutOrFailure(false, consistencyForConsensus, failedAttemptsDueToContention);\n\n                    case SUCCESS:\n                        return serialReadResult(begin.readResponse);\n\n                    case SUPERSEDED:\n                        Superseded superseded = propose.superseded();\n                        // TODO https://issues.apache.org/jira/browse/CASSANDRA-18276 side effects shouldn't matter for reads\n                        switch (superseded.hadSideEffects)\n                        {\n                            default: throw new IllegalStateException();\n\n                            case MAYBE:\n                                // We don't know if our update has been applied, as the competing ballot may have completed\n                                // our proposal.  We yield our uncertainty to the caller via timeout exception.\n                                // TODO: should return more useful result to client, and should also avoid this situation where possible\n                                throw new MaybeFailure(false, begin.participants.sizeOfPoll(), begin.participants.sizeOfConsensusQuorum, 0, emptyMap())\n                                      .markAndThrowAsTimeoutOrFailure(true, consistencyForConsensus, failedAttemptsDueToContention);\n\n                            case NO:\n                                minimumBallot = propose.superseded().by;\n                                // We have been superseded without our proposal being accepted by anyone, so we can safely retry\n                                Tracing.trace(\"Paxos proposal not accepted (pre-empted by a higher ballot)\");\n                                if (!waitForContention(deadline, ++failedAttemptsDueToContention, group.metadata(), group.queries.get(0).partitionKey(), consistencyForConsensus, READ))\n                                    throw MaybeFailure.noResponses(begin.participants).markAndThrowAsTimeoutOrFailure(true, consistencyForConsensus, failedAttemptsDueToContention);\n                        }\n                        break;\n                }\n            }\n        }\n        finally\n        {\n            // We don't base latency tracking on the startedAtNanos of the RequestTime because queries which involve\n            // internal paging may be composed of multiple distinct reads, whereas RequestTime relates to the single\n            // client request. This is a measure of how long this specific individual read took, not total time since","sourceCodeStart":937,"sourceCodeEnd":973,"githubUrl":"https://github.com/apache/cassandra/blob/88fd0f6a0eaed8943f05ac9e8f947882b8ddc8f1/src/java/org/apache/cassandra/service/paxos/Paxos.java#L937-L973","documentation":"During the Paxos proposal phase, a MAYBE result means the coordinator cannot determine whether its update was applied — a competing ballot may have completed the proposal. Cassandra surfaces this uncertainty as a WriteTimeoutException ('Operation timed out') marked as a timeout rather than a failure, telling the client the result is unknown and must be resolved.","triggerScenarios":"Concurrent LWT/transactional writes to the same partition: our proposal was superseded or uncertain (MAYBE) after the propose phase, so the coordinator throws MaybeFailure which is delivered to the client as a timeout with unknown outcome.","commonSituations":"Hot-row contention where multiple clients CAS the same partition concurrently; retried LWTs colliding with fresh attempts; applications not handling 'operation timed out — unknown result' after LWTs; heavy contention causing repeated timeouts on the same key.","solutions":["Re-read the row to determine the actual outcome before retrying (LWT timeouts mean unknown, not failure)","Reduce contention on the partition: shard hot keys, add jitter/backoff to retries, or redesign to avoid CAS on a single hot row","Use the driver's LWT contention-retry policy or application-level exponential backoff","For multi-key/high-contention workloads, consider Accord transactions instead of Paxos LWT"],"exampleFix":"// before: blind retry on LWT timeout\n} catch (WriteTimeoutException e) { retryInsert(row); }\n// after: verify outcome first\n} catch (WriteTimeoutException e) {\n    Row r = readRow(key); // serial read to learn actual state\n    if (!applied(r)) retryInsertWithBackoff(row);\n}","handlingStrategy":"retry","validationCode":"// minimize contention before issuing CAS\nlong waits = session.execute(\"SELECT writetime(v) FROM t WHERE k=?\", key).one() != null ? 1 : 0; // detect hot key usage\n// add jittered backoff between attempts","typeGuard":null,"tryCatchPattern":"try { rs = session.execute(cas); }\ncatch (WriteTimeoutException e) {\n    // outcome unknown: read current state to decide, then retry with backoff\n    if (!wasApplied(readCurrentState(key))) retryWithJitteredBackoff();\n}","preventionTips":["Always treat LWT timeout as 'unknown outcome' and re-read before retrying","Shard or queue writes to hot partitions to reduce CAS contention","Use exponential backoff with jitter on LWT retries","Consider Accord transactions for high-contention workloads"],"tags":["paxos","lwt","timeout","contention"],"backgroundTag":"request-timeout","analyzedSha":"88fd0f6a0eaed8943f05ac9e8f947882b8ddc8f1","analyzedAt":"2026-09-10T07:29:22.284Z","contentChangedAt":"2026-09-10T07:29:22.284Z","schemaVersion":2},"datasetVersion":"2026-09-14T16:17:12.679Z"}