Skip to main content

Durability

XCON Quee is at-least-once. The constitution: on restart, nothing acknowledged is lost, and redelivery is bounded. Exactly-once is not claimed.

Four layers back this:

  1. Producer ack after fsync. Publish returns only after the engine has durably appended the message. XCON Quee connects to xcon-db in strict durability mode and asserts it — a producer ack means the row is on disk.
  2. Durable exception state. A subscription checkpoints not just its cursor but the attempt counts and the acked-ranges above the cursor. After a restart, in-flight attempts survive and already-acked messages are suppressed, so a poison message still reaches the DLQ and an ack is never silently lost.
  3. DLQ invariant. The cursor never advances past a message whose dead-letter append is not yet durable — a failed message cannot be dropped between "gave up" and "recorded".
  4. CAS fence. Cursor checkpoints are compare-and-swap against a fence held in the engine, so a stale broker cannot overwrite a newer owner's progress.

What redelivery looks like​

A consumer that receives a message and dies before acking will see it again (at-least-once) — make handlers idempotent (an IdemKey on publish helps de-duplicate at the source). A fenced handoff redelivers only the work that was in-flight at the moment of takeover; acknowledged work is not replayed.

Gap signal​

If a subscription's cursor ever falls behind the engine's live horizon (for example, the topic was truncated out from under a lagging reader), the messages between the old cursor and the horizon are skipped and counted in a durable, operator-visible GapSkipped counter — at-least-once honestly degrading to at-most-once, never silently.