v1.3 Continuous replication stops on change tracker error

Our client app is reporting on the replication state and needs to ensure the continuous replication never goes into a stopped state else this can be confusing when trying to diagnose issues.

According to CB Lite API Documentation the stopped state represents the following: “Stopped: A one-shot replication goes into this state after all documents have been transferred or a fatal error occurs. (Continuous replications never stop.)” Note: continuous replication should never stop and always go into a re-try AwaitingChanges state by default

But I’ve seen it is possible for continuous replication to go into a stopped state. When the change tracker experiences a non-transient error and there are no more changes left to download it calls: ProcessChangeTrackerStopped And in that method the following logic is called which puts continuous replication in a stopped state:

 if (ChangesCount == CompletedChangesCount && IsSafeToStop) {
      Log.To.Sync.V(TAG, "Change tracker stopped, firing StopGraceful...");
      FireTrigger(ReplicationTrigger.StopGraceful);
  }

We are looking to deploy to production soon with v1.3 but I am worried that the continous replication can go into a “stopped” state as we assumed this was not possible, and as I said, can be confusing when trying to diagnose issues.

Would you be able to suggest a workaround in the interim. I’m prepared to just resolve my side in a Fork if necessary. Can I simply add a “&& !Continuous” check to the above logic. Any suggestions would be much appreciated.

[borrrden]

Ok I brought this up with the team and we are going to once and for all make a document with the definitive answer for this since we cannot all seem to remember the same version. So far it seems that continuous replication should never stop, as in the docs and so I will move forward with that in mind. After the document has been reviewed and finalized I will make the final changes.

P.S. What is the error that causes the stoppage?

[borrrden]

@Steven-Mark-Ford I refactored the retry logic into a completely central place to make it more unit testable, but it’s a pretty big change so I pushed it up onto a branch. If you want, you can give the source on the issue/718 branch a shot and see if your issue resolves.