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.

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

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.

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

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.

On Nov 13, 2012, at 6:54 PM, lenkawell <len.kaw...@pepper.com<mailto:len.kaw...@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<https://github.com/couchbaselabs/TouchDB-iOS/issues/186> for details on how to use it.

—Jens