lite→Origin document sync: pushed CRDT deltas are acked but never materialize into a shape-servable collection (ShapeSnapshot doc_count=0)

[emanzx]

Summary

A Lite replica can push document CRDT deltas to Origin and they are accepted (acked, server LSN advances, a CRDT checkpoint is persisted) — but the data never becomes servable: a fresh Lite shape-subscribing the same collection gets an initial ShapeSnapshot with doc_count=0. So the lite->Origin push path works, but the Origin->lite serve path returns nothing. The round-trip (write on one replica -> read on another via Origin) does not complete.

Repro

1. Origin running (trust auth), sync WS on :9090.
2. From a Lite replica, write ~1,537 documents into collection entries with sync enabled. Observe in the Lite log: pushed deltas to Origin, delta acknowledged rtt_ms~8, FtsIndexAck ... accepted=true for every doc.
3. From a fresh Lite replica, ShapeSubscribe { ShapeType::Document { collection: "entries", predicate: [] } }.

Observed: ShapeSnapshot { doc_count: 0, snapshot_lsn: 3577, data: [1 byte] } — identical for tenant_id 0, 1, and 2.

Evidence the pushes were received

• Origin snapshot_lsn = 3577 (advanced from the pushes).
• /data/<inst>/crdt-ckpt/tenant-tenant:0.ckpt ~= 20 MB, written right after the sync.
• Every delta was acked back to the pusher.

Evidence the collection is not served

• SHOW COLLECTIONS on Origin -> 0 rows. SELECT ... FROM entries -> "table not found".
• Round-trip ShapeSnapshot.doc_count = 0 in all tenants.

Is this expected / known?

The repo's own interop test acknowledges the serve side is stubbed — nodedb-lite/tests/sync_interop_shape.rs:137:

"Origin does not currently fan-out ShapeDelta back over the same connection as the delta pusher. We simulate Origin's fan-out by directly feeding a ShapeDelta frame through the SyncClient handler..."

Two questions:

1. Is Origin-side materialization of pushed document deltas into a servable collection implemented for 0.1.0, or known-unimplemented?
2. Is the intended flow that the collection must be created on Origin first (DDL) before Lite pushes/subscribes? If so it isn't documented; if not, pushed deltas aren't being materialized.

Scope note

The CRDT protocol itself is solid — handshake, real Loro delta push, ack, reconnect, and the sync_interop_live suite all pass against a real Origin. This is specifically about the serve/materialize half of lite<->Origin document sync.

[emanzx]

Note on layer scope, since pagedb#6 was just fixed with a related-sounding symptom:

NodeDB-Lab/pagedb#6's fix #2 ("incremental apply never advanced the trees — applied segments and key/value data were unreachable on the follower even after promotion") rhymes with this issue's symptom (pushed deltas accepted/promoted but unreachable on read). But I checked: nodedb (Origin) does not depend on pagedb — that fix is lite-side. So it does not carry over to this Origin-side document-serve gap; this remains open.

Flagging it anyway in case the same class of bug exists in the Origin's own materialization path — i.e. pushed document CRDT deltas are committed/checkpointed but the target collection root the shape snapshot reads from is never advanced, so ShapeSnapshot.doc_count stays 0. If the Origin's snapshot/materialize path has an analogous "never advanced the target root" defect, the fix shape may mirror pagedb#6's.

Still reproduces on current main (Origin LSN advances to 3577 from the pushes, 20MB crdt-ckpt persisted, but shape round-trip = 0 docs in all tenants).