couchbase-lite-core icon indicating copy to clipboard operation
couchbase-lite-core copied to clipboard

API access to replicator's `activeOnly` mode

Open iwasrobbed-ks opened this issue 5 years ago • 7 comments

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

iwasrobbed-ks avatar Feb 13 '20 19:02 iwasrobbed-ks

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)

iwasrobbed-ks avatar Feb 13 '20 19:02 iwasrobbed-ks

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.

snej avatar Feb 13 '20 21:02 snej

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

iwasrobbed-ks avatar Apr 03 '20 19:04 iwasrobbed-ks

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.

borrrden avatar Apr 20 '20 23:04 borrrden

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

iwasrobbed-ks avatar Apr 23 '20 19:04 iwasrobbed-ks

What is the status of action items here? @pasin Does this need an API ticket?

borrrden avatar Sep 17 '20 12:09 borrrden

Migrated to CBL-3670

jianminzhao avatar Sep 09 '22 17:09 jianminzhao