[zxch3n]

Related issue

Follow-up to the desktop traffic and persistence investigation #1815.

Problem / pressure

A remote update B can be received before its causal predecessor A without advancing the applied version or emitting an applied event. The previous Promise Repo save path could lose B across a restart. In the real CLI SQLite regression, the existing dependencies restore base|A instead of base|AB after A arrives.

Summary

Adopt the actual published loro-crdt 1.17.0 and loro-repo 0.24.0 through the workspace catalog, exact CLI runtime dependency and frozen registry lock. Repo now retains received pending inputs in the existing storage journal. Keep release-age exceptions restricted to the reviewed exact versions. The old core override remains confined to the standalone Loro CLI test tool.

Add import/importBatch SQLite restart regressions, update the owning README and bilingual adoption note, and link the historical investigation to this implemented follow-up. Snapshot tests now drive current-tick cooperative work while awaiting sync and cleanup; their explicit debounce clock and business assertions remain unchanged. Storage schema, Streams cursor policy and recovery limits are unchanged. This addresses a reproduced persistence gap; it does not establish the reported 80 GB traffic's cause or implement a download budget.

Visual explanation

flowchart LR
  B[Receive B before A] --> P[Keep B pending]
  P --> J[Flush existing SQLite journal]
  J --> R[Restart and restore B]
  R --> A[Receive missing A]
  A --> AB["Recover base|AB"]
  AB --> S[Save and reopen again]

Loading

Before / after

Before	After
A pending-only update can disappear on restart; later A produces base|A.	Received B survives flush/restart; later A produces base|AB, including after another reopen.

Test plan

• Old registry dependencies: both new SQLite cases failed with the expected missing B; actual released dependencies: both pass.
• Default pnpm install --frozen-lockfile passed. All 41 core files and 103 files in each Repo peer variant match the official SRI-verified tarballs. CLI, components, shared, e2ee-lab and their Streams/Mirror/Adaptor/WebSocket peers resolve the same Core instance within their runtime domain. No candidate/file override remains.
• Full pnpm check on the dependency adoption passed before the clock-fixture correction: includes CLI 4,518 passed / 4 skipped, components 5,967 passed, shared 1,609 passed, complete type/static/boundary checks and the remaining workspace suites. Isolated session-injected Git state (GIT_EXEC_PATH and helper precedence in PATH) after an old/new dependency control proved it polluted the Git fixture; no Git source or test assertion was weakened. The post-fixture rerun repeated that known environment failure; all 24 Git tests pass with native Git first in the test PATH. The final component suite passed 5,967/5,967. Final-head CI and final-head desktop E2E both passed.
• A controlled storage/clock probe reproduced the frozen fairness-yield failure seen in the first CI attempt. With the test fix, all 37 owning cases and a temporary rejection-identity probe passed; nine real cooperative yields completed, while every helper wait kept the mock clock unchanged. Production code and the original test/hook timeouts are unchanged.
• pnpm format, document checks (0 errors; 71 existing warnings) and independent source/lock/artifact review passed.
• Real CLI build passed, including published import/native-runtime smoke and WASM staging. The actual emitted Core/Repo chunks pass 16 SQLite recovery assertions; desktop native dependency/worker staging passed 6/6.

Upstream implementation and publication: Loro #1220, Repo #165, Repo 0.24.0 release #166. User-device Nightly acceptance and production traffic measurements were not performed.