Strange counters on replicator Couchbase Lite 2.5.3 / Syncgateway 2.5.1

Good morning,
I would like to understand better the numbers coming from the replicator status
I have this little piece of code

    ReplicatorConfiguration replConfig = new ReplicatorConfiguration(database, targetEndpoint);
    replConfig.setReplicatorType(ReplicatorConfiguration.ReplicatorType.PUSH_AND_PULL);
    replConfig.setAuthenticator(new BasicAuthenticator(USER_NAME, PASSWORD));
    replConfig.setContinuous(true);

    this.replicator = new Replicator(replConfig);

    this.replicator.addChangeListener(change -> {
       Progress progress = change.getStatus().getProgress();
        Log.d(Session.TAG, String.format(Locale.US, "replicator %d / %d", progress.getCompleted(), progress.getTotal()));
        CouchbaseLiteException tw = change.getStatus().getError();
        if (tw != null) {
            Log.i(Session.TAG, tw.getMessage(), tw);
        }
    });
    this.replicator.start();

but I noted in the log I have this strange output

2019-09-30 12:10:20.749 4998-4998: replicator IDLE 33725 / 43893 <- nothing was updating
2019-09-30 12:10:20.849 4998-4998: replicator BUSY 33725 / 43893 <- start updating
2019-09-30 12:10:20.877 4998-4998: CHANGED 1 documents <- 1 doc
2019-09-30 12:10:21.044 4998-4998: replicator BUSY 33726 / 43894 <- still updating
2019-09-30 12:10:21.048 4998-4998: replicator IDLE 33726 / 43894

I can see the numbers before and after the updating is consistent (only 1 document increased the counter for both total and completed), but between completed and total the numbers are really far each other.

I am using the counters to show an updating progress, and you can see as those 2 numbers (completed vs total) are not reliable.

Thanks for any feedback.

As indicated in the docs, these counters should not be used for tracking progress. IIRC, those units are quite arbitrary and it could vary between doc counts or bytes depending on whether we know the size of doc as yet. Since the sync happens in batches, computing a fraction isn’t very useful either.
If you are interested in tracking replication status of specific document(s), use the replication event
In a future release, we are considering bringing back an API that will allow you to query for pending documents that have not yet been pushed.

As indicated in the docs, these counters should not be used for tracking progress

But you can use them for UI purposes, i.e. divide the two numbers (as floats of course) to come up with a fraction to display in a progress bar.

“completed” and “total” should becomes equal when the replicator goes idle or finishes. There have been some bugs in the past that broken this, but I’m not aware of any in 2.7.

The units are intended to be, roughly, byte counts. But they’re extremely approximate. It turns out that doing accurate progress measurement is not compatible with replicating quickly — it would require a lot of extra work on the server and a lot of extra network traffic — so we don’t do it.

Thanks everbody.
I used to use completed and total for UI purpose, just to inform you I can see the replication becomes idle before to get the 100% event. It’s not a big issue on our side, but if you need more logs I can send you something.