2026-09-25 10:32:13 +02:00
|
|
|
|
---
|
|
|
|
|
|
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).
|
2026-09-25 10:41:59 +02:00
|
|
|
|
|
|
|
|
|
|
## Implementation evidence update — 2026-09-25
|
|
|
|
|
|
|
|
|
|
|
|
[Frontend recovery review](../reviews/FrontendRecoveryImplementations.md) 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.
|
2026-09-25 11:02:03 +02:00
|
|
|
|
|
|
|
|
|
|
## Executable observation — 2026-09-25
|
|
|
|
|
|
|
|
|
|
|
|
[Matrix SDK experiment](../reviews/MatrixRecoveryExperiment.md) 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.
|
2026-09-26 21:22:53 +02:00
|
|
|
|
|
|
|
|
|
|
## 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](../evaluations/language-pilot-01/submitted-review-01/adjudication.md),
|
|
|
|
|
|
not new observations of provider guarantees.
|
