mirror of
https://github.com/johannesjo/super-productivity.git
synced 2026-07-18 08:56:41 +00:00
c41c18f247
* fix(sync): guard fresh-client first sync against data-loss trap & decrypt-race A genuinely-fresh client seeds example tasks before its first sync, so on first connect to a populated, encrypted SuperSync dataset it hit a SYNC_IMPORT conflict dialog whose USE_LOCAL would overwrite the real remote, plus a red DecryptNoPasswordError. - A1: SyncImportConflictGateService flags isNeverSynced (\!hasSyncedOps) on the incoming-import dialog; the dialog guards the destructive USE_LOCAL with a confirm and focuses the scenario-appropriate safe button via cdkFocusInitial. - B: OperationLogDownloadService logs 'encrypted ops, no key' quietly only for a genuinely-fresh client (never synced AND no local encryption flag); it stays loud (dropped-credential signature) for already-synced clients and for a wiped op store whose config still flags encryption on, via the new optional provider method SuperSync.isEncryptionEnabled(). - D: SuperSync.isReady() returns false while isEncryptionEnabled && \!encryptKey, keeping a self-inconsistent encrypted config out of auto-sync; shares the _isEncryptionHalfConfigured predicate with getEncryptKey(). Tests: super-sync isReady/isEncryptionEnabled, conflict-gate isNeverSynced, dialog confirm-guard + focus-by-scenario, download severity branches, and a sync-service end-to-end first-sync-trap guard. Plan/rationale: docs/plans/2026-06-03-fresh-client-first-sync-data-loss-trap.md * docs(sync): add fresh-client first-sync data-loss-trap plan Documents the shared root cause (example tasks seeded pre-first-sync), the A1/B/D fixes, and the accepted Fix C residual (example-task pollution onto non-encrypted accounts) with the rationale for deferring an identity-based cleanup. * fix(sync): capture never-synced guard pre-download for piggyback SYNC_IMPORT The SYNC_IMPORT conflict gate's never-synced guard (which blocks a fresh client from force-overwriting a populated remote via USE_LOCAL) was computed from a live hasSyncedOps() read on the piggyback-upload path. By the time that gate runs, the same sync has already persisted downloaded ops with syncedAt and marked accepted uploads synced, so the flag flips to "has synced" mid-cycle and the guard disarms itself — re-opening the data-loss trap on the piggyback path. Capture the never-synced snapshot once at sync-cycle start, before download, and thread it through downloadRemoteOps()/uploadPendingOps() into the gate. The gate falls back to a live read only for standalone callers (download gate is safe live: nothing is persisted until processRemoteOps). Also stop the sync-wrapper catch from re-logging the expected DecryptNoPasswordError at error level — the download/upload service already logs it at the right severity, so re-logging undid the fresh-client onboarding-prompt quieting. Tests: gate honors a caller-provided isNeverSynced without consulting live history; piggyback path flags isNeverSynced=true even when the upload marks ops synced; wrapper threads the pre-download snapshot. Refresh the plan doc's stale test counts and document the fix (§11). |
||
|---|---|---|
| .. | ||
| super-sync.spec.ts | ||