Skip to content

fix(sync): keep reading when the store refuses an upload - #451

Open
A-EDev wants to merge 1 commit into
mainfrom
fix/sync2-upload-refusal
Open

A-EDev wants to merge 1 commit into
mainfrom
fix/sync2-upload-refusal

Conversation

@A-EDev

@A-EDev A-EDev commented Nov 7, 2026

Copy link
Copy Markdown
Collaborator

Summary

A store refusing one object stopped the whole sync on a server group: upload_pending ran with ? before push and pull, so nothing more was read either. Writes on a WebDAV group stopped the run the same way.

Now:

  • On a server group, an object the server refuses is held and queued like one written during an outage. Objects go up in the order they were written, so nothing is skipped and nothing goes ahead of it, since readers stop at a gap in a log.
  • Uploading runs after the exchange, so reading and applying are done first.
  • On any store, a refused write no longer stops reading. The run finishes, garbage collection included, then returns the error, which reaches the existing last-sync status and the dashboard's recent errors.
  • A refused sign-in and a server that lost the group still end the run at once.

Related issue

None.

Change type

  • Bug fix

Validation

  • cargo fmt --all: run before committing.
  • cargo test --test sync2_hybrid in src-tauri: passed. The new test fails on main at push, and fails if new writes aren't queued behind what was refused.
  • cargo test --test sync2_engine --test sync2_snapshots --test sync2_gc --test sync2_lan: passed.
  • CI runs the full suite on this PR.
  • service.rs needs an AppHandle and has no test, so the order in run and the WebDAV path were checked by reading only.
  • Not smoke-tested in a window or on a device.

Risk and compatibility

No format change. An object that stays refused keeps this device's later objects queued, and the error shows on every sync. This change doesn't unstick such a log: other devices wait at the gap, and later writes stay held locally, and on the LAN for peers.

  • No new secrets, private data, telemetry, or broad Tauri permissions were introduced.

Copilot AI balanced review requested due to automatic review settings November 7, 2026 14:05

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants