Logseq DB Sync over Cloudflare
Replace Logseq RTC with db-sync over Cloudflare: a simpler sync model for DB graphs covering local change capture, server merge and conflict handling.
Results
Each square represents one run. Score is the percentage of runs that pass: 0, 25, 50, 75, or 100 for four runs.
| # | Model | Rollouts | Pass@1 | Score | Time |
|---|---|---|---|---|---|
| 1 | GPT-6.1 Sol max | 3/4 | 4.0h | ||
| 2 | Claude Opus 5.5 max | 2/4 | 3.5h | ||
| 3 | GPT-6 Astra xhigh | 1/4 | 3.8h | ||
| 4 | Qwen3.8 Max xhigh | 1/4 | 3.8h | ||
| 5 | Grok 4.7 xhigh | 1/4 | 2.5h | ||
| 6 | GPT-5.6 Sol max | 0/4 | 2.8h | ||
| 7 | Gemini 3.8 Flash high | 0/4 | 1.7h | ||
| 8 | GLM 5.3 Flash max | 0/4 | 3.8h | ||
| 9 | Muse Spark 1.3 max | 0/4 | 3.7h | ||
| 10 | Kimi K3 max | 0/4 | 3.6h | ||
| 11 | Claude Sonnet 5.5 max | 0/4 | 3.7h |
Background
Logseq is an open-source outliner whose newer DB graphs keep pages and blocks in a DataScript database (an in-memory triple store). It is replacing RTC sync with db-sync: the server keeps an authoritative, append-only transaction log per graph and does no merging. Each client uploads DataScript transactions, applies others' changes and rebases pending work. Rebasing local edits over remote ones can create parent cycles, orphan blocks under a remotely deleted page, collide sibling orders or loop a class hierarchy, and every client must still converge, including after long offline sessions.
Task
The agent writes the sync engine in the DB worker behind a pinned set of functions: record every local transaction as a pending change, build an upload batch, drop accepted changes, and apply pulled remote data while rebasing pending work. The server protocol is fixed: a batch is accepted only against the latest log position, and pulls return transactions in log order. Rebasing replays local changes after remote ones, with the local value winning on the same attribute. A change that would break an invariant yields while the rest apply. Deletes cover whole subtrees. DB validation, parent and page consistency, acyclic hierarchies and distinct sibling orders hold after every step.
Workspace
The offline sandbox (4 CPUs, 8 GB, 4 hours) holds a full-history Logseq checkout with Node 22, Java 17, the Clojure CLI and every dependency installed. Worked examples include a small in-process server. The multi-client harness and its seeds are held out.
Verification
The committed HEAD is rebuilt from a clean checkout in a separate environment. A hidden harness drives two or three clients against a protocol-conforming server over 23 families of 12 seeded scenarios each: targeted conflicts, online and offline sessions, and randomized mixes of concurrent edits, moves, deletes and deep trees. Invariants are checked after every step, then convergence and rebase-rule outcomes. Seven targeted families must pass every scenario and the other 16 at least 90%, and the main ClojureScript suite and three library suites must still pass.
Environment
- Toolchain
- ClojureScript, TypeScript
- Compute
- 4 CPUs · 8 GB RAM
- Network
- Offline
- Time limit
- 4 hours
References
- Logseq: The knowledge base whose DB worker the agent extends.
- DataScript: The in-memory database behind DB graphs; the synced unit is its transaction data.