frontend-patterns/research/candidates/MutationOutcomeTracking.md
tegwick 78bd951568 Exercise Matrix SDK recovery under controlled transport failures
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
2026-09-25 11:02:03 +02:00

3.1 KiB
Raw Blame History

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.