# What invariants prevent a FIFO-assuming handler from mis-sequencing on a reordering transport?

**Date of Record:** 2026 November 2

**Scope:** Applies to message handlers that assume messages arrive in the order sent, on transports that do not guarantee ordering (UDP, multi-path TCP, message brokers with multiple consumers, replay channels). Does not apply to handlers that operate on total-order transport with verified ordering guarantees.

## Core Distinction

FIFO is a property of the transport, not of the messages. A handler that assumes FIFO is a handler that has not distinguished "the sender put A before B" from "the receiver saw A before B". On a reordering transport, both orderings of the same send sequence are possible, and the handler's assumption is a defect masked by the common case.

**Invariant.** Sequential correctness holds if and only if `handler_enforces_order(sequence_key)` or `transport_guarantees_order(channel)`. Absent either, order-dependent operations must be re-expressed as commutative or idempotent.

**Violation.** The **FIFO Illusion**. The handler applies state transitions assuming A→B. The transport delivers B→A. The handler applies B, then A; the resulting state differs from the intended A-then-B. Neither the send nor the delivery is wrong; the assumption is.

**Asymmetry.** Send-order is visible to the sender. Delivery-order is visible to the receiver. The two are visible to different parties, and neither sees the discrepancy — only the resulting state.

**Recorded elements.** The `sequence-key-receipt` (whether a sequence key is present and what it orders), the `transport-guarantee-receipt` (what ordering the transport actually provides), and the `reorder-sensitivity-signature` (whether operations commute) together make soundness checkable.

## What Was Observed

**Signature.** State divergence between two replicas that received the same messages. Not a missing message — the set is identical — but the state depends on the arrival order and the two replicas saw different orders.

**Trace.** Two messages: `SET x=1`, `SET x=2` (send order). Replica A receives 1→2, state x=2. Replica B receives 2→1, state x=1. Both are internally consistent. Both are correct given their own arrival order. The diverging state is attributed to "replication lag" or "a bug in replica B", not to a FIFO assumption on a reordering transport.

**Why monitoring stays green.** Both replicas report successful message application. Both are healthy. Ordering is not observable from either replica's own metrics.

## Condition of Validity

The instance must ensure at least one holds before it applies an order-dependent handler:

1. **Must enforce order at the handler.** A sequence key is present, the handler buffers or waits until the sequence is complete, and out-of-order arrival is not applied until in-order.
2. **Must confirm transport ordering.** The transport is verified to provide ordered delivery for the channel in question, and the guarantee is not assumed from the transport name.
3. **Must express operations commutatively.** Operations are provably commutative or idempotent, so order does not affect the final state.

Condition 3 is the only one that survives transport changes without coordination.

## Decision Boundary

- Handler enforces order via sequence key: sound.
- Transport guarantees order, verified: sound for that channel.
- Transport assumed ordered without verification: unsound; verify before relying.
- Operations commutative: sound regardless of transport.

## Operational Effect

The invariant couples a handler's assumption to a transport's guarantee. The instance's correct posture is to make the order dependency explicit and either enforce it or eliminate it.

**Trap.** Add a sequence number. A sequence number is only useful if the handler *uses* it to buffer and order; merely attaching one is inert. The fix is to consume the sequence key at the handler, not to embed it at the sender.

```python
from dataclasses import dataclass


class FifoAssumptionError(RuntimeError):
    """Raised when an order-dependent handler runs on a transport that may reorder messages."""


@dataclass(frozen=True)
class OrderingGate:
    handler_enforces_sequence: bool
    transport_order_verified: bool
    operations_commutative: bool

    def verify(self) -> bool:
        if self.operations_commutative:
            return True
        if self.handler_enforces_sequence:
            return True
        if self.transport_order_verified:
            return True
        raise FifoAssumptionError(
            "order-dependent handler on unverified transport: reorder produces divergent state"
        )


def dispatch_ordering_mode(gate: OrderingGate) -> str:
    try:
        gate.verify()
    except FifoAssumptionError:
        return "buffer-and-order-by-sequence"
    return "apply-in-order"
```