Optimistic UI and Delivery Receipts: Defining What Sent Means

The visible problem may look like one API or tuning value, but reliability is decided by state ownership, resource bounds, and recovery after failure. Optimistic insertion improves responsiveness but is not delivery. Status advances monotonically from evidence, and failure should preserve content with a retry path.

Frontend architecture is about state ownership, repeatable events, invalidation of stale async work, and cleanup after unmount—not the shape of the source directory.

Make the implementation decisions explicit

Turn the important choices into durable contracts: validate inputs, assign state ownership, define cleanup, and specify fallback for older peers. Later optimization must not change those semantics.

• Generate a stable client message ID and show queued immediately without server renumbering.
• DataChannel send advances sending; peer ACK advances delivered; read uses a separate receipt.
• Retry with the original ID and content, and reject late receipts that regress terminal state.

Optimistic UI may show intent early but cannot invent peer facts. Evidence-backed states keep the experience both fast and honest.

Failure paths that are easy to miss

Production failures often appear when two individually valid actions overlap. Inspect stale messages, duplicate effects, exhausted resources, and mixed versions instead of patching only the current stack frame.

• Queueing in bufferedAmount is shown as delivered even though the peer is offline.
• Retry creates a new ID and both attempts receive ACKs, duplicating the message.
• Read receipts expose behavior without a privacy control or product explanation.

How to verify it before release

Build golden cases from known inputs and controlled faults, then align production metrics with those results. Verification extends to production only when signals detect the same degradation early.

1. Disconnect and refresh both peers at queued, sending, delivered, and read states.
2. Drop an ACK, retry, then deliver the original ACK late; one message remains monotonic.
3. Disable read receipts and verify neither protocol nor UI implies reading.

Completion is not one passing path. Every terminal state reconciles, automation stays below user intent, and every operational cost has an explicit ceiling.