tegwick
d7b2ea49ce
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
48 lines
2.5 KiB
Markdown
48 lines
2.5 KiB
Markdown
---
|
||
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).
|
||
|
||
## 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.
|