Skip to content

Sync on unlock, off by default (0.9.0) - #12

Merged
usermaneGermane merged 1 commit into
mainfrom
sync-on-unlock
Nov 8, 2026
Merged

usermaneGermane merged 1 commit into
mainfrom
sync-on-unlock

Conversation

@usermaneGermane

Copy link
Copy Markdown
Owner

Sync on unlock (0.9.0)

TODO step 4 (owner, 2026-11-06): a setting, off by default.

  • Settings → Sync → "Sync when I unlock": a switch, shown once sync is set up. On, PassMan syncs ~0.4 s after the vault opens (the window draws first). A conflict still waits for your choice. If the server can't be reached you get a warning ("Not synced — the server can't be reached…"), not an error, and the vault is open either way.
  • Per vault and per PC: it's kept with the vault's sync settings. A merge keeps this PC's own choice, and a vault restored onto a new PC starts with it off.
  • Fix for a race this makes more likely: a sync can now be running when you lock. A late result no longer touches a locked vault, or another vault unlocked since (sync_ui._still_open, an unlock/lock counter). It also no longer pops a confusing error after the lock. Locking during a sync skips its safety-net save, which could otherwise land after the merge and put the pre-merge copy back on disk.

No vault-format change. README: the sync section and the feature list.

Tests

  • tests/test_sync_on_unlock.py, 20 tests: default off, only a real True counts, needs a server, survives an address edit, a merge keeps this PC's choice, a restore starts off; late prepare/commit/mismatch results after lock; the window's delayed start; lock vs a running sync.
  • Mutation-checked: removing the guard, saving during a sync, defaulting to on, ignoring the switch, skipping the session check before the start, and keeping the switch on restore each make the tests fail.
  • Full suite: 377 passed, 3 skipped (on Windows). Same code as PassMan for Windows 2.11.0 (PR 3.0 phase 1b for Linux: local accounts + 2.x import (1.0.0-alpha.1, Lab only) #14); sync_client, sync_ui (bar the cert placeholder) and dialogs are identical.
  • Lab end-to-end (E:\CLAUDE\PassMan\Lab\dev-shots\flows_unlock.py, a throwaway server on 127.0.0.1:8797 with its own store in Lab): 15/15 on this source too. It checks: off by default; the switch is saved; another PC's entry arrives on unlock; lock at once → no sync; lock mid-sync → nothing comes back and no error; the next unlock catches up; server down → the vault opens with a warning. The missing guard fails it.

🤖 Generated with Claude Code

https://claude.ai/code/session_011ojnyVg7ccsR3pZ64s7aRH

Settings -> Sync gets a "Sync when I unlock" switch once sync is set up. On,
PassMan syncs a moment after the vault opens; a conflict still waits for the
user's choice, and an unreachable server is a warning, not an error. Stored
with the vault's sync settings, so it is per vault and per PC; a vault
restored onto a new PC starts with it off.

A sync can now be running when the vault is locked, so a late result no
longer touches a locked vault (or one unlocked since): sync_ui._still_open
checks an unlock/lock counter. Locking during a sync skips its safety-net
save, which could otherwise put the pre-merge copy back on disk.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011ojnyVg7ccsR3pZ64s7aRH
@usermaneGermane
usermaneGermane merged commit fc935dc into main Nov 8, 2026
6 checks passed
@usermaneGermane
usermaneGermane deleted the sync-on-unlock branch November 8, 2026 21:53
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.

1 participant