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.