409 retry can result in invalid remote ancestor ID
Description
This is an edge case, but was reported in a CBSE. If a backup of a server bucket is made, but replication continues, and then later the bucket is restored this invalidates the remote ancestors in the local database and causes a lot of conflicts that end up in a situation where CBL thinks that the parent rev ID is the same as the current rev ID. Half a day of research went into this so it's not easily summarized here but basically the checkpoint is rewound, causing a replication restart in which for some reason the remote ancestor persists so when the pusher goes to send certain revisions the sequence goes something like this:
1. Send doc gen 2 with no parent 2. 409 received 3. Lookup remote ancestor and retry with remote ancestor (this fails because the remote ancestor is the same gen 2 revision ID)
Build couchbase-lite-net-3.1.0-24 contains couchbase-lite-core commit e07fa42 with commit message: : Puller needs to consider the kSynced flag (#1309) (#1350)
CB robot January 19, 2022 at 6:11 PM
Build couchbase-lite-android-3.1.0-105 contains couchbase-lite-core commit e07fa42 with commit message: : Puller needs to consider the kSynced flag (#1309) (#1350)
CB robot January 19, 2022 at 6:07 PM
Build couchbase-lite-java-3.1.0-103 contains couchbase-lite-core commit e07fa42 with commit message: : Puller needs to consider the kSynced flag (#1309) (#1350)
CB robot January 18, 2022 at 12:15 AM
Build couchbase-lite-c-3.1.0-68 contains couchbase-lite-core commit e07fa42 with commit message: : Puller needs to consider the kSynced flag (#1309) (#1350)
CB robot January 15, 2022 at 8:00 AM
Build couchbase-lite-ios-3.1.0-84 contains couchbase-lite-core commit e07fa42 with commit message: : Puller needs to consider the kSynced flag (#1309) (#1350)
Fixed
Pinned fields
Click on the next to a field label to start pinning.
This is an edge case, but was reported in a CBSE. If a backup of a server bucket is made, but replication continues, and then later the bucket is restored this invalidates the remote ancestors in the local database and causes a lot of conflicts that end up in a situation where CBL thinks that the parent rev ID is the same as the current rev ID. Half a day of research went into this so it's not easily summarized here but basically the checkpoint is rewound, causing a replication restart in which for some reason the remote ancestor persists so when the pusher goes to send certain revisions the sequence goes something like this:
1. Send doc gen 2 with no parent
2. 409 received
3. Lookup remote ancestor and retry with remote ancestor (this fails because the remote ancestor is the same gen 2 revision ID)