frontend-patterns/research/candidates/PendingSynchronization.md
tegwick 642163a1ed Refine recovery guidance and explore navigation and rendering
Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a0cffe-206f-7323-89d3-b20ca4cf4bf9
2026-09-26 21:22:53 +02:00

2.4 KiB

title status maturity families scales admission
Pending Synchronization draft hypothesis
synchronization
L2
L6
research-candidate-only

Pending Synchronization

Context: edits persist while connectivity is absent or intermittent. Problem: local success does not establish a remote receipt. offline-usability competes with freshness; retries add reconciliation-complexity.

Proposed solution: retain stable revision/operation identity and pending work across restart, retry on reconnection, and distinguish queued, sent and acknowledged states. A sent request alone never means synchronized. Define deduplication and the acknowledgement scope at the receiver before retrying. Do not infer that every other device has seen it.

Result: progress can resume after interruption without relying on volatile UI state. A lost response leaves the same operation pending; an idempotent retry or lookup must resolve uncertainty. Infinite retries, expired authorization and sync-disabled items need explicit observable states rather than a permanent spinner.

Evidence: expansion review E05/E06 documents Joplin's distinct sync process and per-item progress metadata. The precise retry protocol here is a hypothesis, not a verified implementation description. Known uses of the full contract and recurrence: unknown. Alternative: server-required writes, which sacrifice offline operation; untracked best-effort upload, which lacks restart recovery.

Proposed connections: Local Commit Boundary provides a persistent origin; detected divergence may create context for Conflict Copy. Neither relation implies every sync needs a conflict copy. See the VC-02 walkthrough.

Supersession contract — 2026-09-26

If reconciliation replaces pending operation P with revision c and operation Q, commit c, Q and P's superseded/non-retryable status in one recoverable transaction. After a restart, the queue must not retry P as active work. An already transmitted P cannot be recalled by this local transaction: the receiver still needs appropriate version/ancestry preconditions or reconciliation. A late receipt for P updates P's history, never clears Q or overwrites c. Trace both crash boundaries and in-flight races before asserting this contract. This is proposed guidance, not an executed storage test; see shared guidance revision.