FAILURE MAP
← Case archive

FA-75952 / Chat ordering and read receipts / Member archive

Fold out-of-order delivery events into a recipient status: retry source · case 02

A retry signal resets a delivered message back to queued.

Member previewVariant 2 · 3 implementations · 9 checks per implementation

Case contract

events are [seq, kind] with kind in queued, sent, delivered, read, failed, retry, processed in (seq, kind) order. Ranks queued<sent<delivered<read and status never regresses. failed only applies while queued or sent; retry moves failed back to queued; after a failure only delivered or read evidence (not a stale sent) replaces it. Result {status, history} where history lists every status change starting at queued.

Why this case matters

Per-recipient ticks are assembled from events that arrive out of order across transports.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixtureActualExpectedOutcome
retry after read{"history": ["queued", "read", "queued"], "status": "queued"}{"history": ["queued", "read"], "status": "read"}Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.

Sign in to the archive ↗