super-productivity/packages
Johannes Millan 18262eb1f3
fix(sync): retention pruning, misc→tasks alias boundary & WS local-win re-upload (#9028)
* fix(supersync): exclude legacy REPAIR from retention cleanup pruning

The daily-cleanup fallback (used when `latestFullStateSeq` is absent, i.e.
legacy/pre-marker installs) selected the pruning boundary with a raw
`opType: { in: [SYNC_IMPORT, BACKUP_IMPORT, REPAIR] }` filter that includes
legacy REPAIR rows (`repairBaseServerSeq` NULL). Such a repair carries no
causal base cursor proving its state is current as of its seq, so pruning
history behind it can permanently drop ops committed between its logical
base and its seq for any device replaying from before it.

#8971 migrated five full-state queries to `CAUSAL_FULL_STATE_OPERATION_WHERE`
but missed this one — the single query whose result directly authorizes a
DELETE. Route it through the same causal-only predicate; a legacy-repair-only
user then yields `protectedFromSeq === null` and is skipped (no deletion),
the safe default already implemented below.

Adds a regression test whose mock `findFirst` honours the causal
`repairBaseServerSeq` predicate.

* fix(supersync): gate misc→tasks conflict alias on the split boundary

`detectConflictForEntity` and `prefetchLatestEntityOpsForBatch` looked up
the legacy `GLOBAL_CONFIG:misc` alias for an incoming `tasks` write with
`schemaVersion < CURRENT_SCHEMA_VERSION`. Once v4 shipped, that aliases
post-split v2/v3 misc writes — disjoint from `tasks` — and fabricates false
`CONFLICT_CONCURRENT` rejections of tasks-settings writes for multi-device
users.

Gate both read-side lookups on the fixed `MISC_TASKS_SPLIT_SCHEMA_VERSION`
(2), matching the `isLegacyMiscConfigOperation` incoming gate and the
warning comment it already carries. Drops the now-unused
`CURRENT_SCHEMA_VERSION` import.

Adds real-PostgreSQL integration coverage for both changed lookups
(`detectConflictForEntity` and the batch `prefetchLatestEntityOpsForBatch`):
a post-split v2/v3 misc write must not alias, a legacy v1 one still must.

* fix(sync): re-upload LWW local-win ops after a WS-triggered download

A WS-triggered download that resolves a conflict against pending local ops
appends LWW local-win replacement ops straight to the op-log, bypassing the
capture effect. Unlike `ImmediateUploadService` and the main sync loop, this
path had no follow-up upload, so the preserved edit sat unsynced until the
next user edit or periodic sync — an unbounded window for manual-sync-only
users.

Re-upload when `localWinOpsCreated > 0`, mirroring the other two paths, and
surface the same terminal outcomes `ImmediateUploadService` does — permanent
rejection / rejected-full-state baseline → ERROR, mandatory-but-missing key →
UNKNOWN_OR_CHANGED — so a preserved edit that fails to converge is not left
silent (the WS path never claims IN_SYNC). Single follow-up only, matching the
sibling side channel.

* fix(supersync): validate the primary latestFullStateSeq marker as causal before pruning

The scheduled retention cleanup trusted `state.latestFullStateSeq` as a pruning
boundary whenever it was `<= lastSnapshotSeq`, with no check that the marked op is
a causal full-state operation. The earlier fix (37bf818) hardened only the
fallback query used when the marker is absent.

Installs upgraded from before #8973 can carry a `latestFullStateSeq` set from a
legacy REPAIR (repairBaseServerSeq NULL) through the old isFullStateOpType gate,
and that migration shipped no backfill to clear stale markers. Trusting such a
marker prunes history behind a repair the replay path deliberately refuses as a
boundary (LegacyRepairReplayUnsupportedError) — permanent, cross-device loss.

Validate the marked op against CAUSAL_FULL_STATE_OPERATION_WHERE before it can
authorize a DELETE; a stale marker drops to the (now causal-only) fallback query
or the user is skipped. Updates the happy-path test to a causal boundary, adds a
stale-marker regression test, and teaches the mock findFirst to honour an exact
serverSeq predicate.

* test(e2e): de-flake USE_REMOTE crash-resume reload

`page.reload()` defaulted to waiting for the `load` event, which can never
fire while an active SuperSync WebSocket/sync connection keeps the page
"loading" — so the reload timed out at 30s (observed flake:
`page.reload: Timeout 30000ms exceeded`). Three sibling sync specs already
document this hang and work around it with close()+newPage(), but that drops
sessionStorage, which this test asserts on across the reload.

Wait only for `domcontentloaded` (with 60s headroom) instead; `waitForAppReady`
— which itself only needs `domcontentloaded` — remains the real readiness gate,
and the reload still preserves sessionStorage.
2026-07-15 13:12:04 +02:00
..
plugin-api feat(plugin): add PluginAPI.request with manifest allowedHosts allowlist (#8721) 2026-07-07 11:50:17 +02:00
plugin-dev fix(plugins): prevent automation rule data loss (#8972) 2026-07-13 19:12:13 +02:00
shared-schema fix(sync): make marked project deletions win LWW conflicts (#9009) 2026-07-14 19:58:33 +02:00
super-sync-server fix(sync): retention pruning, misc→tasks alias boundary & WS local-win re-upload (#9028) 2026-07-15 13:12:04 +02:00
sync-core fix(sync-core): break whole-entity LWW timestamp ties by clientId (#9035) 2026-07-15 13:03:09 +02:00
sync-providers fix(sync): file-based provider atomicity & conflict UX (#8960) (#9004) 2026-07-14 19:23:24 +02:00
vite-plugin chore(deps): bump esbuild in the npm_and_yarn group across 0 directory (#8451) 2026-06-17 14:41:32 +02:00
build-packages.js fix(plugin): refresh procrastination buster i18n #5102 (#8145) 2026-06-08 20:44:43 +02:00
README.md feat: cleanup and update plugins 2 2025-06-29 06:36:02 +02:00

Super Productivity Packages

This directory contains plugin packages and the plugin API for Super Productivity.

Structure

  • plugin-api/ - TypeScript definitions for the plugin API
  • plugin-dev/ - Plugin development examples and tools
    • api-test-plugin/ - Basic API test plugin
    • procrastination-buster/ - Example SolidJS-based plugin
    • yesterday-tasks-plugin/ - Simple plugin showing yesterday's tasks
    • boilerplate-solid-js/ - Template for creating new SolidJS plugins (not built)
    • sync-md/ - Markdown sync plugin (not built)

Building Packages

All packages are built automatically when running the main build process:

npm run build:packages

This command:

  1. Builds the plugin-api TypeScript definitions
  2. Builds plugins that require compilation (e.g., procrastination-buster)
  3. Copies plugin files to src/assets/ for inclusion in the app

Development

To work on a specific plugin:

cd plugin-dev/[plugin-name]
npm install
npm run dev

Adding a New Plugin

  1. Create a new directory in plugin-dev/
  2. Add the plugin configuration to /packages/build-packages.js
  3. Run npm run build:packages to test the build

Notes

  • The boilerplate-solid-js and sync-md plugins are development templates and are not included in production builds
  • Plugin files are automatically copied to src/assets/ during the build process
  • The build script handles dependency installation automatically