frontend-patterns/research/candidates/MutationOutcomeTracking.md

title	status	maturity	families	scales	admission
Mutation Outcome Tracking	draft	hypothesis	mutation synchronization	L2 L6	research-candidate-only

Mutation Outcome Tracking

Context: a remote write can finish even when its response disappears. Problem: transport failure leaves acceptance uncertain. Recoverability competes with latency, retention cost and backend complexity.

Proposed solution: track each attempt as pending, accepted, explicitly rejected or unknown. Bind retry identity to the original payload and authority scope. Resolve unknown outcomes through a documented operation lookup or idempotent replay within its retention contract. Changed intent gets a new identity. Without such a contract, require reconciliation rather than claiming an automatic retry is safe.

Consequences: feedback can be honest about uncertainty; operation history consumes resources. Expired receipts and lost identity need an unresolved recovery path. Timeout, cancellation or a generic server error alone cannot prove rejection. Disabling a button limits interaction, not server execution or duplication.

Evidence: T03 documents Stripe's bounded idempotency mechanism; T04 demonstrates why browser cancellation is insufficient. Neither establishes this full frontend state model or a second independent known use. Recurrence: unknown. Hypothesis only.

Proposed connection: acceptance enables Invalidate and Reproject. Compare Pending Synchronization: local commit can already be valid there while remote propagation remains unacknowledged.

T01–T05 refer to TransactionalEvidenceExpansion. Connections are research proposals, not admitted graph edges. Reasoning exercise: VC-01.

Implementation evidence update — 2026-09-25

Frontend recovery review R02/R04–R06 locates failed-send recovery and echo reconciliation in two frontend families. These are partial uses, not verified implementations of all four proposed states. NOT_SENT or failed_request may reflect missing confirmation, not proven rejection. Correlation IDs, server deduplication and authoritative acceptance require separate evidence. A later matching authoritative event can resolve uncertainty; stale errors must not overwrite stronger evidence. Keep hypothesis maturity; assess whether this is best retained as a shared review model rather than a standalone pattern.

Executable observation — 2026-09-25

Matrix SDK experiment X01–X03 executes retry and early-echo behavior with a synthetic receiver. A rejected send promise can coexist with an already reconciled event. Separate transport-attempt outcome from domain evidence. Cancelling a local pending record does not revoke a remotely accepted operation; issuing a new identity afterward can duplicate logical intent. This is one partial implementation observation in the Element/Matrix family, not independent recurrence or proof of real-server deduplication.

Recovery contract — 2026-09-26

Before retrying, record how to recover the original operation identity, look up its outcome, and determine the receiver's deduplication scope and retention window. Outside that window, replay may create a second effect; lookup or reconciliation must resolve the original outcome before fresh submission of the same logical intent. If neither can resolve it, keep uncertainty visible and escalate the domain decision rather than describing a fresh identity as safe.

Distinguish stopping a local wait, cancelling a pending remote action, and reversing an accepted effect. State the authority's cancellation preconditions and race behavior; if acceptance wins, only a separately authorized reversal/compensation can undo its domain effect, and some effects have no reversal. Track that operation's outcome too. These are design requirements prompted by the submitted review, not new observations of provider guarantees.