stackchain/stackchain-dashboard
1
0
Fork 0
Code Issues 9 Pull Requests 1 Actions Packages Projects Releases 713 Wiki Activity

Prevent stale offline Later edits from overwriting newer plans #377

New Issue
Closed
opened 2026-08-09 06:29:43 +00:00 by rockachopa · 0 comments
rockachopa commented 2026-08-09 06:29:43 +00:00
Member
Copy Link

Problem

An offline device can replay an old Later defer/restore after another device has changed the same item. Current arrival-order application silently overwrites the newer account plan while the UI reports success. Reproduced on current main (f686e2e): device B syncs a newer wake time, then device A reconnects and replaces it with its older queued value.

Scope

Make Later synchronization causally conflict-safe per item: queue each operation with its base revision, persist per-item change revisions (including restore tombstones), reject stale same-item intent without blocking unrelated operations, return explicit receipts and authoritative state, and surface a conflict-specific operator status.

Acceptance criteria

  • A stale defer cannot replace a newer defer or resurrect a newer restore.
  • A stale restore cannot erase a newer defer.
  • An old operation for an unchanged item still succeeds.
  • Mixed batches independently receipt accepted, duplicate, and stale_intent operations.
  • Replayed stale operation IDs are idempotent and do not mutate state.
  • The client removes receipted stale operations, adopts server truth, and reports another-device conflict rather than ordinary saved status.
  • Existing account scoping, batching, retries, and cross-tab behavior remain intact.
  • Focused tests and full suite pass; the offline shell cache is bumped.

Non-duplication evidence

No open issue or PR covers planning conflicts. Historical #361 only rejects older response snapshots; #363/#365/#373/#375 cover persistence, retry, tab loss, and batching, not stale operation admission. All 191 historical issue titles and recent commits were checked.

## Problem An offline device can replay an old Later defer/restore after another device has changed the same item. Current arrival-order application silently overwrites the newer account plan while the UI reports success. Reproduced on current main (`f686e2e`): device B syncs a newer wake time, then device A reconnects and replaces it with its older queued value. ## Scope Make Later synchronization causally conflict-safe per item: queue each operation with its base revision, persist per-item change revisions (including restore tombstones), reject stale same-item intent without blocking unrelated operations, return explicit receipts and authoritative state, and surface a conflict-specific operator status. ## Acceptance criteria - A stale defer cannot replace a newer defer or resurrect a newer restore. - A stale restore cannot erase a newer defer. - An old operation for an unchanged item still succeeds. - Mixed batches independently receipt accepted, duplicate, and `stale_intent` operations. - Replayed stale operation IDs are idempotent and do not mutate state. - The client removes receipted stale operations, adopts server truth, and reports another-device conflict rather than ordinary saved status. - Existing account scoping, batching, retries, and cross-tab behavior remain intact. - Focused tests and full suite pass; the offline shell cache is bumped. ## Non-duplication evidence No open issue or PR covers planning conflicts. Historical #361 only rejects older response snapshots; #363/#365/#373/#375 cover persistence, retry, tab loss, and batching, not stale operation admission. All 191 historical issue titles and recent commits were checked.
timmy was assigned by rockachopa 2026-08-09 06:29:43 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
P0

Drop everything

  
P1

High priority

  
P2

Medium priority

  
agent:nightprowl

Assignments routed to the LongCat NightProwl evaluation worker

  
backend

Backend service

  
ci

Continuous integration / actions

  
frontend

Frontend / UI

  
meta

Meta / planning

  
pages

Gitea Pages

  
template

Repo template / standards

No Label
P0
P1
P2
agent:nightprowl
backend
ci
frontend
meta
pages
template
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
timmy
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: stackchain/stackchain-dashboard#377
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?