Outcome
A public, per-session "initial load complete" signal on the collection: a boolean plus a subscription, reset when a sync session starts, set when the session's first sync commit lands. Sync adapters could then delete the equivalent flag they each maintain, and useLiveQuery consumers could tell "ready because this session loaded data" apart from "ready because of a seed or a revival".
Why the existing signals do not cover it
Our adapter falls back to a cached snapshot until the collection has loaded in the current sync session. The public signals answer a different question:
collection.isReady() and status: 'ready' describe the collection's lifetime. They stay true after a GC-and-revive cycle, although the revived instance's data was cleared. They also stay true when a load fails after an earlier success. A read gate built on them serves an empty or stale collection instead of the healthy fallback.hasBeenReady is per-session but private (collection._lifecycle) and has the same revival behavior.
What we do today
We keep a boolean in the collection-options scope: set on snapshot commit, reset on every sync start, exposed through collection.utils with a subscribe. It works, but it duplicates state the library already tracks.
Outcome
A public, per-session "initial load complete" signal on the collection: a boolean plus a subscription, reset when a sync session starts, set when the session's first sync commit lands. Sync adapters could then delete the equivalent flag they each maintain, and
useLiveQueryconsumers could tell "ready because this session loaded data" apart from "ready because of a seed or a revival".Why the existing signals do not cover it
Our adapter falls back to a cached snapshot until the collection has loaded in the current sync session. The public signals answer a different question:
collection.isReady()andstatus: 'ready'describe the collection's lifetime. They stay true after a GC-and-revive cycle, although the revived instance's data was cleared. They also stay true when a load fails after an earlier success. A read gate built on them serves an empty or stale collection instead of the healthy fallback.hasBeenReadyis per-session but private (collection._lifecycle) and has the same revival behavior.What we do today
We keep a boolean in the collection-options scope: set on snapshot commit, reset on every sync start, exposed through
collection.utilswith a subscribe. It works, but it duplicates state the library already tracks.