Skip to content

CONCEPT Cited by 1 source

Request cancellation

Definition

Request cancellation is the elector-initiated action of deleting a tentative request across followers during a leadership change, such that it is "as if it never took place." It is the terminal alternative to completion in the two-phase completion protocol.

Sugu Sougoumarane's canonical wiki framing: "If a cancellation message is received, the follower can delete the request, as if it never took place." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-6-completing-requests).

The mutual-exclusion invariant

"Completion and cancellation are mutually exclusive: A request that was completed will never be canceled, and a request that was canceled will never be completed."

This is the load-bearing safety property. A tentative request in a correct implementation follows exactly one of two terminal paths: complete (applied) or cancel (deleted). Not both. Never both.

Who can cancel, and when

Cancellation is not the leader's prerogative. From Sugu:

"A leader that fails to make a request durable can keep retrying, but it must not attempt to cancel the request. This is because an elector could be performing a leadership change and may attempt to propagate the failed request."

Cancellation is the elector's prerogative during a leadership change. The elector is the entity that knows the full state of in-flight work across followers and can decide, per tentative request, whether to:

  • Propagate it — if it appears on enough followers to re-derive durability under the new leader, complete it.
  • Cancel it — if it does not meet durability, delete the tentative record across followers.

The tentative-vs-durable distinction is what makes this decision safe: a durable request must be propagated (it cannot be cancelled); a non-durable tentative request is the elector's choice.

Follower-side behaviour

Upon receiving a cancel message, a follower:

  1. Locates the tentative record (by request identifier).
  2. Deletes the payload and the marker.
  3. Does not materialise the effect. No variable changes, no row is written.

Cancellation is local and idempotent — receiving two cancel messages for the same tentative request is harmless; the second one finds no record.

Contrast with MySQL semi-sync

MySQL semi-sync has no cancellation vocabulary because its replicas apply-on-receive — there is no tentative state to delete. On a leader crash, this produces the semi-sync split-brain hazard: writes that were never durable are already applied on some replicas, so there is nothing for a replacement coordinator to cancel — it must either accept the write (and potentially publish a never-durable write) or do deep manual reconciliation.

Relation to forward progress

The retry-not-cancel rule for leaders (see concepts/forward-progress) is a direct consequence of the two-actor ownership split:

  • Leader owns completion (materialise the effect once durable).
  • Elector owns cancellation (delete abandoned tentative records during a leadership change).

If the leader could also cancel, a slow leader retrying and a new elector cancelling could race — leading to either double-application or lost work.

Seen in

Last updated · 347 distilled / 1,201 read