@glance-apps/sync 1.5.2 → 1.6.0

package/CHANGELOG.md

@@ -7,6 +7,85 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.6.0] - 2026-07-10
+
+### Fixed
+
+- **DB engine: a pulled delete no longer unconditionally beats a newer local
+  edit.** `applyRemoteRow` applied a pulled `deleted: true` row without any
+  timestamp comparison AND pruned the entity from the dirty set, so a device
+  that edited an entity offline (with a newer `lastModified`) and then pulled a
+  peer's delete before pushing silently discarded its own newer edit — the
+  opposite of the engine's upsert conflict rule and of the file tier's
+  newest-write-wins over tombstones. Deletes now participate in the same
+  entity-grain LWW: the engine stamps each pushed soft-delete with a
+  `deletedAt` (epoch ms, taken at push time) and applies a pulled delete only
+  when the local copy's `lastModified` does not exceed that stamp. When the
+  local edit is strictly newer, the delete is discarded and the entity is
+  marked (or kept) dirty so the next push re-upserts it over the tombstone and
+  restores the row fleet-wide.
+  - **Tie-break:** on an exact timestamp tie the DELETE wins (unlike the upsert
+    rule, where local wins ties), because `deletedAt` is stamped at push time
+    and therefore already post-dates the deleting device's own last edit.
+  - **Backward compatibility:** a tombstone with no `deletedAt` — from a
+    GLANCEvault server that predates the stamp, or a row deleted by an older
+    client — keeps the previous unconditional delete-wins behavior. `deletedAt`
+    rides the DELETE request as an extra query param, which old servers ignore.
+- **DB engine: push sends upserts before deletes, closing the transient
+  fleet-wide delete window.** `pushDirtyRows` used to issue the per-entity
+  `deleteRow` calls before the batched upserts. A cross-list move (delete
+  `unscheduledTasks:X` + upsert `tasks:X` in the same dirty set) that failed
+  between the two steps (5xx / network drop) left the delete on the server with
+  no replacement row, so every peer pulled a bare delete and the entity
+  vanished fleet-wide until the origin device successfully retried. The batch
+  upsert now runs first; a failure between the steps leaves the benign inverse
+  (both rows briefly exist) and the retained dirty set retries both
+  idempotently. No invariant depended on the old order: upserts and deletes in
+  one push can never share an `entityId`, and `maxSeq`/ack accounting is
+  order-independent.
+
+### Changed — behavior notes for consumers
+
+- Delete/edit races now resolve by newest-write-wins instead of delete-always-
+  wins. An entity edited on one device *after* (per wall clock) another
+  device's deletion will be **restored on all devices** rather than deleted.
+  Apps relying on "delete always sticks" semantics should treat this as a
+  breaking behavior change. Clock skew caveat: `deletedAt` comes from the
+  deleting device's clock at push time, so a device with a fast clock can win
+  conflicts it shouldn't — same trust model as the existing `lastModified` LWW.
+- During a partial push failure, peers may transiently observe a moved entity
+  in both its old and new lists (previously: in neither) until the retry lands.
+- Unchanged (regression-guarded): upsert LWW keeps local on ties and prunes a
+  remotely-superseded entity from the dirty set; the split pull/push cursors
+  and their persistence keys; the exported `getRow` vault surface and
+  `decryptEntity`; push idempotency for re-sent upserts and soft-deletes.
+
+### Added
+
+- `createVaultClient().deleteRow(app, entityId, accountId, { deletedAt })` —
+  optional fourth argument; the stamp is sent as a `deletedAt` query param.
+  `VaultPulledRow` gains an optional `deletedAt` field.
+
+## [1.5.3] - 2026-07-04
+
+### Fixed
+
+- **Generic WebDAV auto-backups now nest under the app folder instead of the
+  server root.** The `webdav` backup provider built its upload directory as the
+  bare WebDAV root (`<webdavUrl>/`), so backups landed at
+  `<webdavUrl>/<prefix><ts>.json`. On NAS targets whose base URL is the server
+  root (Synology/fnOS), a `PUT` to `/` is rejected with `405 Method Not Allowed`
+  because writes are only permitted inside a shared folder, so auto-backups
+  silently failed (lifeGLANCE issue #206). The provider now writes to
+  `<webdavUrl>/<appFolderName>/backups/` — matching how the sync file path
+  (`<webdavUrl>/<appFolderName>/<syncFilename>`) and the `nextcloud` backup
+  provider (`<appFolder>/backups/`) are constructed — and issues an `MKCOL` for
+  the app folder and the `backups/` subdir on a `404`/`409` before retrying the
+  `PUT`, so the first backup to a fresh target succeeds. `listBackups`,
+  `downloadBackup`, `deleteBackup`, and retention all target the same nested
+  directory. The folder segment comes from `appFolderName` (the sync folder),
+  not the dead `config.folder` field.
+
 ## [1.5.2] - 2026-06-19
 
 ### Fixed
@@ -295,7 +374,10 @@ entire sync infrastructure can be shared across the GLANCE app family.
 - TypeScript declarations in `types/index.d.ts`.
 - WebDAV CORS proxy handler in `api/webdav-proxy.js`.
 
-[Unreleased]: https://github.com/glance-apps/glance-sync/compare/v1.1.2...HEAD
+[Unreleased]: https://github.com/glance-apps/glance-sync/compare/v1.6.0...HEAD
+[1.6.0]: https://github.com/glance-apps/glance-sync/compare/v1.5.3...v1.6.0
+[1.5.3]: https://github.com/glance-apps/glance-sync/compare/v1.5.2...v1.5.3
+[1.5.2]: https://github.com/glance-apps/glance-sync/compare/v1.5.1...v1.5.2
 [1.1.2]: https://github.com/glance-apps/glance-sync/compare/v1.1.1...v1.1.2
 [1.1.1]: https://github.com/glance-apps/glance-sync/compare/v1.1.0...v1.1.1
 [1.1.0]: https://github.com/glance-apps/glance-sync/compare/v1.0.3...v1.1.0

package/README.md

@@ -114,7 +114,7 @@ Pass `encryptionEnabled: true` in the sync config object stored via `engine.setC
 |--------|-------------|
 | `sync()` / `download()` | Full cycle: download → validate → merge → apply → upload if changed. |
 | `upload(opts?)` | Upload local state to the remote provider. |
-| `runBackup(frequency)` | Save a snapshot to IDB and upload it to the remote backup folder. |
+| `runBackup(frequency)` | Save a snapshot to IDB and upload it to the remote backup folder (`<appFolderName>/backups/`, a sibling of the sync file inside the app folder). |
 | `test(config)` | Test the connection to the configured provider. |
 | `getConfig()` / `setConfig(cfg)` | Read/write the persisted sync config (credentials, provider, flags). |
 | `getLastSynced()` | ISO 8601 timestamp of the last successful sync. |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@glance-apps/sync",
-  "version": "1.5.2",
+  "version": "1.6.0",
   "license": "MIT",
   "type": "module",
   "main": "src/index.js",

package/src/autoBackup.js

@@ -195,7 +195,12 @@ export function createAutoBackupProviders(config) {
         { key: 'appPassword', label: 'Password / App Password', type: 'password', placeholder: 'your-password' }
       ],
       _getBackupDirUrl(providerConfig) {
-        return `${providerConfig.webdavUrl.replace(/\/+$/, '')}/`;
+        // Nest backups under the app folder (mirroring the sync file path
+        // `${webdavUrl}/${appFolderName}/${syncFilename}` and the nextcloud
+        // provider's `${appFolder}/backups/`). Writing to the bare WebDAV root
+        // fails with 405 on NAS targets (Synology/fnOS) that only permit PUT
+        // inside a shared folder.
+        return `${providerConfig.webdavUrl.replace(/\/+$/, '')}/${appFolder}/backups/`;
       },
       _getAuthHeaders(providerConfig) {
         return { 'X-WebDAV-Auth': 'Basic ' + toBase64(providerConfig.username + ':' + providerConfig.appPassword) };
@@ -213,6 +218,11 @@ export function createAutoBackupProviders(config) {
           wdFetch('PUT', fileUrl, authHeaders, body, { 'Content-Type': 'application/json' });
         let res = await doUpload();
         if (res.status === 404 || res.status === 409) {
+          // Create the app folder before the backups/ subdir so the first
+          // backup to a fresh target doesn't 404/409 (mirrors the nextcloud
+          // provider). MKCOL on an existing collection is a harmless no-op.
+          const parentDir = `${providerConfig.webdavUrl.replace(/\/+$/, '')}/${appFolder}/`;
+          await wdFetch('MKCOL', parentDir, authHeaders);
           await wdFetch('MKCOL', dirUrl, authHeaders);
           res = await doUpload();
         }

package/src/dbEngine.js

@@ -373,18 +373,34 @@ export const createDbSyncEngine = (config) => {
       }
     }
 
-    // Soft-delete first, then batch the upserts. If any call throws, we fall out
-    // before clearing the dirty set or advancing the push-ack marker.
+    // Batch the upserts FIRST, then soft-delete. If any call throws, we fall
+    // out before clearing the dirty set or advancing the push-ack marker.
+    //
+    // The order matters for partial-failure safety: a cross-list move puts a
+    // delete ("old-list:X") and its replacement upsert ("new-list:X") in the
+    // same dirty set. Deleting first opened a window where the delete landed,
+    // the batch failed, and every peer pulled a delete with no replacement —
+    // the entity vanished fleet-wide until this device successfully retried.
+    // Upserting first inverts the partial state into a benign one (both rows
+    // briefly exist) that the retried delete cleans up. Nothing depends on
+    // deletes landing first: upserts and deletes in one push never share an
+    // entityId (an entity is either present locally or not), and maxSeq is
+    // order-independent.
+    //
+    // Each delete carries a deletedAt stamp so pulling devices can run LWW
+    // against it (see applyRemoteRow). Servers that predate the stamp ignore
+    // the extra field, in which case pulled tombstones simply lack deletedAt
+    // and fall back to the old delete-wins behavior.
     let maxSeq = getPushAck();
-    for (const entityId of deletes) {
-      const r = await vault.deleteRow(app, entityId, accountId);
-      if (r && typeof r.seq === 'number') maxSeq = Math.max(maxSeq, r.seq);
-      if (r && typeof r.maxSeq === 'number') maxSeq = Math.max(maxSeq, r.maxSeq);
-    }
     if (upserts.length > 0) {
       const result = await vault.batch(app, { accountId, rows: upserts });
       if (result && typeof result.maxSeq === 'number') maxSeq = Math.max(maxSeq, result.maxSeq);
     }
+    for (const entityId of deletes) {
+      const r = await vault.deleteRow(app, entityId, accountId, { deletedAt: Date.now() });
+      if (r && typeof r.seq === 'number') maxSeq = Math.max(maxSeq, r.seq);
+      if (r && typeof r.maxSeq === 'number') maxSeq = Math.max(maxSeq, r.maxSeq);
+    }
 
     // Full acknowledgment: safe to mark clean. Advance the push-ack marker only;
     // the pull cursor stays put so the next pull still lists from the highest
@@ -401,6 +417,29 @@ export const createDbSyncEngine = (config) => {
   // failure — the caller decides whether to quarantine.
   const applyRemoteRow = async (R, dirty) => {
     if (R.deleted) {
+      // A tombstone participates in the same entity-grain LWW as an upsert,
+      // using the deletedAt stamp the pushing device attached (see
+      // pushDirtyRows). A local copy KEEPS only when its lastModified strictly
+      // exceeds deletedAt: the delete wins ties, because deletedAt is stamped
+      // at push time and therefore already post-dates the edit that produced
+      // it on the deleting device. Tombstones from servers/devices that
+      // predate the stamp carry no deletedAt (ts -> 0); those keep the old
+      // unconditional delete-wins behavior.
+      const deletedAt = ts(R.deletedAt);
+      if (deletedAt > 0) {
+        const local = await getLocalEntity(R.entityId);
+        if (local != null && ts(lastModifiedOf(local)) > deletedAt) {
+          // The local edit is newer than the delete: keep it, and make sure it
+          // is dirty so the next push re-upserts it over the tombstone and
+          // restores the row fleet-wide (matching the file tier's
+          // newest-write-wins over tombstones).
+          if (!dirty.has(R.entityId)) {
+            dirty.add(R.entityId);
+            writeDirtySet([...dirty]);
+          }
+          return false;
+        }
+      }
       await applyRemoteDelete(R.entityId);
       if (dirty.delete(R.entityId)) writeDirtySet([...dirty]);
       return true;

package/src/vaultClient.js

@@ -10,7 +10,7 @@
 //   POST   /sync/:app/batch                     upsert rows, returns { written, maxSeq }
 //   GET    /sync/:app/list?accountId=&since=     incremental fetch, { rows, hasMore }
 //   GET    /sync/:app/:entityId?accountId=       fetch one row
-//   DELETE /sync/:app/:entityId?accountId=       soft-delete a row
+//   DELETE /sync/:app/:entityId?accountId=&deletedAt=  soft-delete a row (deletedAt optional)
 //   POST   /sync/:app/device                     update device cursor, { updated }
 //   GET    /salt/:accountId                      fetch the account root-key salt
 //   PUT    /salt/:accountId                      register a salt (first-write-wins)
@@ -127,11 +127,18 @@ export function createVaultClient({ vaultUrl, vaultToken, fetchImpl } = {}) {
     /**
      * Soft-deletes a row by entityId. Returns the server response (may include
      * the new seq for the tombstone).
+     *
+     * opts.deletedAt (epoch ms) stamps the tombstone so pulling devices can
+     * resolve delete-vs-edit conflicts with LWW. It rides as a query param, so
+     * servers that predate the stamp simply ignore it (their tombstones come
+     * back without deletedAt and the engine falls back to delete-wins).
      */
-    async deleteRow(app, entityId, accountId) {
+    async deleteRow(app, entityId, accountId, opts = {}) {
       requireAccountId(accountId, 'delete row');
+      const query = { accountId };
+      if (opts && opts.deletedAt != null) query.deletedAt = String(opts.deletedAt);
       const res = await request('DELETE', `/sync/${encodeURIComponent(app)}/${encodeURIComponent(entityId)}`, {
-        query: { accountId },
+        query,
       });
       if (res.status === 404) return null;
       return jsonOrThrow(res, 'delete row');

package/types/index.d.ts

@@ -396,6 +396,8 @@ export interface VaultPulledRow extends Partial<VaultRow> {
   entityId: string;
   seq: number;
   deleted?: boolean;
+  /** Tombstone LWW stamp (epoch ms or date string). Absent on rows from servers that predate it: the engine then treats the delete as unconditionally winning. */
+  deletedAt?: number | string;
   envelope?: string;
 }
 
@@ -403,7 +405,7 @@ export interface VaultClient {
   batch(app: string, args: { accountId: string; rows: VaultRow[] }): Promise<{ written: number; maxSeq: number }>;
   list(app: string, args: { accountId: string; since: number }): Promise<{ rows: VaultPulledRow[]; hasMore: boolean }>;
   getRow(app: string, entityId: string, accountId: string): Promise<VaultPulledRow | null>;
-  deleteRow(app: string, entityId: string, accountId: string): Promise<{ seq?: number } | null>;
+  deleteRow(app: string, entityId: string, accountId: string, opts?: { deletedAt?: number }): Promise<{ seq?: number } | null>;
   device(app: string, args: { accountId: string; deviceId: string; lastSeenSeq: number }): Promise<{ updated: boolean }>;
   getSalt(accountId: string): Promise<Uint8Array | null>;
   putSalt(accountId: string, salt: Uint8Array): Promise<Uint8Array>;