mirror of
https://github.com/johannesjo/super-productivity.git
synced 2026-07-17 16:37:43 +00:00
8e810edbe7
deleteProject cascade-deletes a project's tasks, notes, sections, repeat config, and archive data in one reducer pass. When that op lost an LWW conflict to a concurrent project edit, only the PROJECT entity was reversed: every client resurrected an empty project and the winning client's status-blind hydration replay cascaded its tasks away after a restart (live state != post-restart replay). Rather than recreate every cascaded entity (payload scales with project size and cannot restore every side effect safely), give schema-v4 deleteProject operations explicit delete-wins precedence: - new deleteProject actions carry a shared PROJECT_DELETE_WINS_MARKER; the shared LWW planner accepts a host-supplied delete-wins classifier. A marked remote delete is applied regardless of timestamps; a marked local delete is replaced with one op whose vector clock dominates both sides. - historical unmarked (schema-v3) deletions keep timestamp-based LWW; the absence of the marker (never added by the no-op v3->v4 migration) is the real discriminator, and a schema v3->v4 barrier (mirroring v2->v3) makes older clients block on the newer-schema gate instead of mis-resolving. Delete-wins plans reuse the archive-win resolution pipeline, so they inherit its atomic persistence and losing-op rejection, and disjoint merge leaves them untouched (the delete must win the whole entity). Hardening from multi-agent review: - union allTaskIds/noteIds across multiple concurrent marked deletes for the same project, so a single replacement cannot leave orphan tasks on clients that only receive it (the task reducer removes by allTaskIds). - gate the classifier on the AUTHENTICATED payload projectId matching the plaintext entityId, so a tampered/replayed delete retargeted onto a live entity cannot silently drop a concurrent edit. - guard a null/undefined delete payload in the classifier instead of throwing and wedging the conflict pass. - pin the server's legacy-misc conflict alias to the fixed v1->v2 split boundary, not CURRENT_SCHEMA_VERSION, so this bump does not fabricate false GLOBAL_CONFIG:misc/tasks conflicts during rollout. - bind the marker with a shared const (compiler-checked on producer and consumer) and rename _isArchivePlan -> _isWholeEntityWinPlan. Documents the policy as ARCHITECTURE-DECISIONS.md #7. Addresses #8997. |
||
|---|---|---|
| .. | ||
| plugin-api | ||
| plugin-dev | ||
| shared-schema | ||
| super-sync-server | ||
| sync-core | ||
| sync-providers | ||
| vite-plugin | ||
| build-packages.js | ||
| README.md | ||
Super Productivity Packages
This directory contains plugin packages and the plugin API for Super Productivity.
Structure
plugin-api/- TypeScript definitions for the plugin APIplugin-dev/- Plugin development examples and toolsapi-test-plugin/- Basic API test pluginprocrastination-buster/- Example SolidJS-based pluginyesterday-tasks-plugin/- Simple plugin showing yesterday's tasksboilerplate-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:
- Builds the plugin-api TypeScript definitions
- Builds plugins that require compilation (e.g., procrastination-buster)
- 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
- Create a new directory in
plugin-dev/ - Add the plugin configuration to
/packages/build-packages.js - Run
npm run build:packagesto test the build
Notes
- The
boilerplate-solid-jsandsync-mdplugins 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