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

Fold out-of-order delivery events into a recipient status: recovery evidence · case 02

Delivery evidence arriving after a spurious failure is ignored, or a stale sent revives the message.

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 fixture	Actual	Expected	Outcome
late delivery after failure	`{"history": ["queued", "sent", "failed"], "status": "failed"}`	`{"history": ["queued", "sent", "failed", "delivered"], "status": "delivered"}`	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.