frontend-patterns/research/candidates/MutationOutcomeTracking.md

38 lines
1.8 KiB
Markdown
Raw Normal View History

---
title: Mutation Outcome Tracking
status: draft
maturity: hypothesis
families: [mutation, synchronization]
scales: [L2, L6]
admission: 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](InvalidateAndReproject.md).
Compare [Pending Synchronization](PendingSynchronization.md): local commit can already
be valid there while remote propagation remains unacknowledged.
T01–T05 refer to [TransactionalEvidenceExpansion](../reviews/TransactionalEvidenceExpansion.md).
Connections are research proposals, not admitted graph edges.
Reasoning exercise: [VC-01](../walkthroughs/VC01-TransactionalAdministration.md).