How to diagnose non-replicating documents

[lenkawell]

I have an iOS app with a TouchDB database that's replicated to Cloudant. There are two documents of about 500 in a specific database on an iOS device that have not been pushed up to Cloudant. That is, the two documents are in the local database, but not in the Cloudant database (I've checked with both Futon and another instance of my app). Other documents in the database seem to be replicating back and forth OK.

Is there some way to diagnose why these documents have not replicated? 

And is there a recommended way to "reset" replication on the device so it tries to replicate those documents again? I currently have a button in the UI that invokes the following method, but it doesn't seem to help in this case: 

// Restart any active syncing (i.e., any persistant replications).

- (void) restartSyncing {

    NSArray* repls = [currentDatabase replications];

    for (CouchPersistentReplication* repl in repls) {

        [repl restart];

    }

}

When I enable lots of TouchDB logging, I see a flurry of activity after invoking this method, but no errors are logged, nor are do the document IDs for the two documents show up in any of the log messages. I'm happy to send along the log, if that'd be useful, though I'd like to learn how to diagnose these problems.

I also tried using the app's Sign Out/Sign In buttons, which deletes the CouchPersistentReplication objects and recreates them, but that didn't seem to get the documents to replicate either.

[Jens Alfke]

On Nov 6, 2012, at 2:17 PM, lenkawell <len.k...@pepper.com> wrote:

Is there some way to diagnose why these documents have not replicated? 

At a high level there are two possibilities, corresponding to whether or not TouchDB ‘knows’ that it hasn’t replicated those documents. If it knows, it’ll keep trying to push them during every replication, and presumably get some sort of error. If it doesn’t know, then the replication checkpoint will have advanced past the last revisions of those documents, so it won’t even be trying.

Replicating with SyncVerbose logging should distinguish the two — look at the logs to see if it ever mentions the IDs of the problematic documents.

In either case there is likely a bug in TouchDB, but the type of bug depends on which kind of failure is occurring.

And is there a recommended way to "reset" replication on the device so it tries to replicate those documents again?

There isn’t, although it would be a good idea to add a mechanism for it. The replication ‘checkpoint’ (the record of the last sequence to be synced) would need to be cleared. That lives in a _local document in both the source and destination database. You could delete that document if you knew its ID, but there’s no way to determine its ID (short of peeking at the localdocs table in the SQLite database.)

(I am not sure whether CouchDB has a mechanism to clear replication state, either.)

—Jens

[lenkawell]

I've turned on SyncVerbose on a few devices and I do not see the missing doc IDs in any of the log messages. If I modify the missing document on the device that has it, the document will then replicate to Cloudant. Likewise, new documents in either device replicate fine. But the fact that the non-replicating documents didn't successfully replicate seems to be forgotten by the replicator. 

Is there anything else I can do to help these users get their databases replicated completely? Any chance there's a way that I can cobble a workaround together to hit the replication checkpoint with a big hammer until there is an official "reset" API? I'm OK with it taking a long time to replicate after the reset.

[Jens Alfke]

On Nov 13, 2012, at 6:54 PM, lenkawell <len.k...@pepper.com> wrote:

Is there anything else I can do to help these users get their databases replicated completely? Any chance there's a way that I can cobble a workaround together to hit the replication checkpoint with a big hammer until there is an official "reset" API? I'm OK with it taking a long time to replicate after the reset.

I figured this would be trivial and started to tell you how to hack it, then realized it wasn’t :) so I added a real implementation. See my comments in #186 for details on how to use it.

—Jens

[lenkawell]

Thanks very much! I'll give it a try.