- Add automated Docker build/push workflow for SuperSync server
- Update docker-compose.yml to use super-productivity org GHCR image
- Add --no-cache flag support to build-and-push.sh script
- Workflow triggers on SuperSync changes or manual dispatch
- Uses GitHub's built-in token (no personal token needed)
Add reusable investigation scripts for analyzing SuperSync storage patterns,
user behavior, and operation anomalies.
New scripts:
- analyze-storage.ts: 9 specialized analysis commands (operation sizes,
timeline, types, large ops, rapid-fire detection, snapshots, user deep-dive,
export, compare users)
- run-all-monitoring.ts: Complete monitoring suite runner with quick mode
and save-to-file options
- MONITORING-README.md: Complete documentation with investigation workflows
New npm scripts:
- npm run analyze-storage -- <command>: Run specific analysis
- npm run monitor:all: Run complete monitoring suite
- npm run monitor:all:quick: Quick health check (skip deep analysis)
- npm run monitor:all:save: Save timestamped report to file
These tools provide structured workflows for investigating storage issues
like rapid-fire operations, unusually large operations, and sync loops.
Tombstones were used for tracking deleted entities but are no longer
needed with the operation log architecture. This removes:
- Tombstone table from Prisma schema
- Tombstone-related methods from SyncService
- Tombstone mocks and tests from all test files
- Database migration to drop tombstones table
The operation log now handles deletions through DEL operations,
making the separate tombstone tracking redundant.
- Add 'ops' command to analyze operation payload sizes
- Show breakdown by entity type with count, total, avg, max sizes
- Display largest operation with payload structure analysis
- Enhance 'usage' command to show ops vs snapshot breakdown
- Show operation count, average size per user
Each run of `npm run monitor -- usage` now saves a snapshot to
logs/usage-history.jsonl. New command `usage-history` shows past
snapshots with growth stats between runs.
- Add disk space info to monitor stats (root filesystem, data dir)
- Add top 5 tables by size to database stats
- Add GHCR login to deploy.sh for private image pulls
Switch from server-side builds to pre-built images:
- Add build-and-push.sh for local builds to GHCR
- Update deploy.sh to pull from registry (30s vs 20min)
- Add docker-compose.build.yml for local build fallback
- Update docker-compose.yml to use registry image
- Add GHCR_USER/GHCR_TOKEN to env.example
- Add npm scripts: docker:build, docker:deploy, docker:backup
This commit introduces a lightweight monitoring CLI tool for the super-sync-server.
Changes include:
- Enhanced logging: now supports writing logs to a file () when is set, enabling persistent log storage.
- New monitoring script: provides commands for:
- : Displays system vitals (CPU, RAM) and database connectivity/size.
- : Shows top 20 users by data storage usage within the database.
- : Allows tailing, searching, and filtering server logs from the file.
- update: Added a script to easily run the tool.
Refactored 'delete-user.ts' and 'clear-data.ts' to use Prisma Client, aligning them with the current PostgreSQL architecture.
Updated 'packages/super-sync-server/README.md' to reflect the Docker-based, PostgreSQL setup and added documentation for the administrative scripts.
Removed '@types/better-sqlite3' from 'package.json' as it's no longer needed.
SYNC_IMPORT, BACKUP_IMPORT, and Repair operations contain full app state
in their payload. When these operations were downloaded by another client
and applied via applyOperations(), convertOpToAction() was spreading the
payload directly into the action. But reducers expect action.appDataComplete,
so they received undefined and fell back to empty/initial state.
This caused complete data loss (no projects, no tags, tasks in wrong project)
when syncing SYNC_IMPORT operations between clients.
Fix: Add extractFullStatePayload() that wraps the payload in appDataComplete
for full-state operation types, matching what loadAllData action expects.
Also clears file-based storage directories in the clear-data script.
Previously, would silently create a new empty database if the configured was incorrect or missing, leading to a confusing 'success' message (deleting 0 rows) while the actual data remained untouched. Now, the script verifies that exists at the expected path before proceeding, and exits with an error if it's missing.
