CBLReplicator.isDocumentPending is inaccurate when replicator is offline

[PaulCapestany]

It seems likeisDocumentPending might not be working as one would expect it to when a device is completely offline.

Setup to reproduce

• CBL (1.2 release)
• Sync Gateway (1.2 release)
• ToDoLite-iOS (patched with minimally invasive sync status feature which displays synced text as black, and unsynced text as grey). Sidenote: relevant PR.

Follow these instructions in order to use Apple's "Network Link Conditioner" to test different connectivity qualities on both the simulator and on actual physical iOS devices.

In the ToDoLite-iOS project, change the kSyncGatewayUrl in AppDelegate.m if need be. Also, make sure that the FacebookAppID and URL Scheme in Info.plist is usable/accurate as well.

Expected behavior

1. When on a good wifi connection, newly added or edited items in any of the tableViews should have black text.
2. When switching to the "Very Bad Network" setting in Apple's "Network Link Conditioner", newly added or edited items in any of the tableViews should have grey text if they haven't been successfully synced within 1.5 seconds (they should turn black again once the replication properly executes however).
3. When putting the testing device in 'Airplane Mode', newly added or edited items in any of the tableViews should have grey text since they're unable to sync, and should turn black again when back on a network connection.

Actual behavior

1. Works as expected.
2. Works as expected.
3. Unexpected behavior. The text of newly added or edited items stays black even though items have not synced due to being in 'Airplane Mode' (and therefore should be grey).

[snej]

Seems like the replicator isn't considering anything as pending while it's in the offline state. I wonder why...

[snej]

Oh, actually it's a simple logic error in CBLReplication. It keeps a cached set of _pendingDocIDs and invalidates it when the replicator's progress changes. But that set should also be invalidated whenever the database changes, because any changed document becomes part of the set.

[snej]

It would be more efficient for CBLReplication to cache the push replicator's lastSequence (an integer.) Then it can implement isDocumentPending: just by comparing the doc's sequence number against that lastSequence.

pendingDocumentIDs requires a query to compute, so maybe it should still be cached. In that case CBLReplication should also keep track of the database's lastSequence at the time it ran the query. Then if lastSequence changes, it means the set is invalidated.

[tleyden]

It would be more efficient for CBLReplication to cache the push replicator's lastSequence (an integer.) Then it can implement isDocumentPending: just by comparing the doc's sequence number against that lastSequence.

That sounds familiar .. from your previous comment #442 (comment):

The push replicator's checkpoint is the sequence number below which all revisions have been uploaded to the server. So we can test whether a doc has been pushed by comparing its current revision's sequence number to the checkpoint. The push replicator already runs a query of all revisions with sequence > checkpoint, to find out which revisions to push — we could expose an API to such a query.