couchbase-lite-core
couchbase-lite-core copied to clipboard
API access to replicator's `activeOnly` mode
Hi there 👋
We're seeing new installs (with an existing sync gateway account) are syncing deleted documents first (or intermixed) ~~even with an empty database~~.
I've seen a reference to an activeOnly
flag but it's not clear how that is set or if it's managed by the client or sync gateway.
Can you please clarify how we can enable installs/reinstalls to only sync active documents? Is this something we can only do using a pull filter or is the core lib supposed to handle this without our intervention?
It's causing quite the delay before renderable documents are displayed.
Thank you!
References:
- https://forums.couchbase.com/t/how-can-i-skip-tombstones-with-the-new-first-time-sync-optimized-backfill-mode/8176/2
- https://github.com/couchbase/sync_gateway/issues/1503
- https://github.com/couchbase/couchbase-lite-ios/pull/1146
Following up: we found that we're actually creating an important document on first install that was created prior to the replicator starting. This seems to have defaulted the replicator into an activeOnly == false
mode.
Is there a way for the client to make this activeOnly
mode more explicit rather than having to wait for the replicator to perform an initial sync? (e.g. in offline first mode)
It would be easy to add an activeOnly
option at the LiteCore level, as a new option key for C4Replicator
. And it's also easy to add an equivalent to CBL's ReplicatorConfiguration.
But it would need to be added to the public API spec, which requires a bit more ceremony. CCing @pasin, who's in charge of the API.
At this point, it doesn't appear that even .stopped
can be trusted since it's not called consistently on fresh installs (even though the docs say it should be)
/// Activity level of a replicator.
///
/// - stopped: The replicator is finished or hit a fatal error.
/// - offline: The replicator is offline as the remote host is unreachable.
/// - connecting: The replicator is connecting to the remote host.
/// - idle: The replicator is inactive waiting for changes or offline.
/// - busy: The replicator is actively transferring data.
This is much more likely
- activity: CouchbaseLiteSwift.Replicator.ActivityLevel.connecting
- activity: CouchbaseLiteSwift.Replicator.ActivityLevel.busy
- activity: CouchbaseLiteSwift.Replicator.ActivityLevel.busy
- activity: CouchbaseLiteSwift.Replicator.ActivityLevel.busy
- activity: CouchbaseLiteSwift.Replicator.ActivityLevel.busy
- activity: CouchbaseLiteSwift.Replicator.ActivityLevel.busy
- activity: CouchbaseLiteSwift.Replicator.ActivityLevel.idle
And we can't use .idle
since the state can easily go from idle
to busy
to idle
again
Any help giving an explicit way to know replication has actually stopped would be 💯so we can actually know when we can perform certain actions with any confidence
Just to clear a few things up: Continuous replications are never supposed to "stop." That is by design. They only go idle automatically unless there is an error, or they are explicitly stopped. If you want a replication to stop when it is "done" use a one-shot replication instead.
Thanks for the extra detail @borrrden 👍 It might be worth clarifying that distinction in https://docs.couchbase.com/couchbase-lite/current/swift.html#replication-status since most folks don't know the underlying API details as well as you all do
What is the status of action items here? @pasin Does this need an API ticket?
Migrated to CBL-3670