v13.11.0
stalwartlabs/stalwartv13.11.0Jul 13, 2026by thedotmack
AI Summary
This release migrates cloud synchronization to be natively integrated into the worker, retiring the standalone `cloud-sync.mjs` daemon. It introduces a new `CloudSync` flusher with robust error handling and a `/cloud-sync` skill, while maintaining full backward compatibility for existing users.
Key Highlights
- Worker-native cloud sync replaces the standalone `cloud-sync.mjs` daemon
- New `CloudSync` flusher with debouncing, single-flight flush, and backoff logic
- New `/api/sync/status` endpoint and `/cloud-sync` skill for management
- Automatic migration for existing users using the legacy daemon
- Fixed session joining and prompt-to-session mapping issues
Breaking Changes
- The standalone `cloud-sync.mjs` daemon is retired and no longer supported.
New Features
- `CloudSync` flusher with write-site nudges, 1.5s debounce coalescing, and capped exponential backoff
- New `GET /api/sync/status` endpoint for pending counts, last flush time, and errors
- New `/cloud-sync` skill for status checks and credential migration from legacy files
- Schema v40 self-repair to re-queue and re-push previously synced prompts
- Fixed race condition where session memory ID registration could mis-key prompt uploads
Full Release Notes
## Worker-native cloud sync (PR #3182) The standalone `cloud-sync.mjs` daemon is retired. The worker now syncs memories itself — every local write nudges a background flusher that drains unsynced rows to cmem.ai, with no separate process to install or babysit. **New:** - `CloudSync` flusher: write-site nudges, 1.5s debounce coalescing write bursts, single-flight flush, 200-row/2MB pages, 30s request timeout, capped exponential backoff on failure - `GET /api/sync/status` — pending counts per kind, last flush time, last error - `/cloud-sync` skill — status checks, first-run credential migration from the legacy `.cloud-sync.env`, daemon retirement, and worker restart runbook **Fixed:** - Prompts now join through `sdk_sessions` to push their real `memory_session_id`/`project` instead of an unresolvable fallback — cloud-side prompt-to-session views (Summary ⇄ Prompt toggle, Replay) can now actually find their prompt - Schema v40 self-repair: on upgrade, every previously-synced prompt (including ones uploaded by the legacy daemon) is re-queued and re-pushed through the fixed mapper; a backfill lane header suppresses realtime broadcast storms during that re-push - Closed a race where a session's memory id registering while its prompt's upload was still in flight could leave that prompt permanently mis-keyed in the cloud — the stamp is now guarded per row and re-pushes with the corrected mapping instead **Migration:** fully automatic and backward compatible. Existing standalone cloud-sync users are migrated on first `/cloud-sync` run after upgrading; installs with no cloud sync configured are unaffected.