Back to Super Productivity

Operation Log & Sync Documentation

docs/sync-and-op-log/README.md

18.16.06.8 KB
Original Source

Operation Log & Sync Documentation

The Operation Log is the single client sync pipeline for SuperSync and file providers. Persistent NgRx actions update the live projection and are captured as durable operations; restart uses a structurally screened snapshot plus the retained operation tail. Vector clocks detect causal order and concurrent edits.

                    Persistent NgRx action
                     ┌────────┴────────┐
                     ▼                 ▼
               NgRx reducers     operation capture
                     │                 │
                     ▼                 ▼
            runtime projection      SUP_OPS
                                  (ops, clocks,
                               checkpoints, snapshot)
                                           │
                                           ▼
                                    Sync Providers
                       ┌───────────────────┴──────────────────┐
                       ▼                                      ▼
                   SuperSync                       File providers
               (ordered op API)           (shared v2 or v3 envelopes)

The v2/v3 envelopes are common adapter formats, not a common physical write guarantee. Dropbox and OneDrive can enforce API compare-and-swap (CAS), while WebDAV/Nextcloud is atomic only when the server supplies strong ETags; weak or missing ETags fall back to a best-effort check. LocalFile likewise has a best-effort read/check/write race and is single-writer/backup-only.

Start here

You want to…Read
Build a five-minute whole-system mental modelsync-architecture.html — standalone maintainer field guide; open the local file in a browser
Write an effect/reducer/bulk-dispatch correctlycontributor-sync-model.md — the one invariant, enforced by lint
Compare SuperSync and file v2/v3field guide: transports
Trace remote apply, conflicts, or restart recoveryremote apply, causality, restart
Research rejected alternatives or cross-version policyoperation-log-architecture.md — deep rationale and migration reference

Reference docs

DocumentScope
sync-architecture.htmlCanonical high-level maintainer map: local intent, transports, crash-safe apply, causality, exceptional boundaries, restart recovery, and executable owners
operation-log-architecture.mdDeep rationale and migration/implementation history; use the focused contracts and executable owners for current detail
contributor-sync-model.mdContributor invariant: one replay-atomic transition = one op; replayed/remote ops must not re-trigger effects
operation-rules.mdDesign rules and guidelines for operations
package-boundaries.mdDependency/ownership boundaries for @sp/sync-core, @sp/sync-providers, app wiring
conflict-journal-and-review.mdDisjoint-field auto-merge plus the device-local journal/review capability; main remote-path journal emission is currently disabled
vector-clocks.mdVector clock implementation, pruning, history
supersync-encryption-architecture.mdEnd-to-end encryption (AES-256-GCM + Argon2id)

Scenario catalogs (expected behavior)

DocumentScope
supersync-scenarios.mdMaintained catalog of SuperSync scenarios and expected behavior
LocationContent
packages/super-sync-server/docs/architecture.mdSuperSync server-only architecture reference
packages/super-sync-server/SuperSync server implementation
ARCHITECTURE-DECISIONS.mdLoad-bearing product/data decisions

Obsolete duplicated walkthroughs and superseded plans live only in git history. Load-bearing ADRs and the explicitly owned migration/rationale sections listed above remain maintained documentation.