Filtered pull replications does not update checkpoint if the result of _changes is empty.
If the remote database has changes that do not match with the filter the last seq is not recorded in the local checkpoint and the same set of changes are reprocessed in each synchronization cycle until a new change match the filtering criteria.
When the remote database has frequent changes but very few match the filtering criteria this issue can derive in a performacen problem.
1. Steps to reproduce and the simplest code sample possible to demonstrate the issue
Create a remote database with some docs
Configure a filtered pull based on a selector that evaluate to false (e.g. a non existent doc id)
Run the pull replication
Check that the checkpoint is not generated in the local documentstore
Run again the pull replication (the since param is not incluided in the _changes request)
2. What you expected to happen
The lastseq should be stored in the local checkpoint even if the changes result is empty
Please read these guidelines before opening an issue.
Bug Description
Filtered pull replications does not update checkpoint if the result of _changes is empty.
If the remote database has changes that do not match with the filter the last seq is not recorded in the local checkpoint and the same set of changes are reprocessed in each synchronization cycle until a new change match the filtering criteria.
When the remote database has frequent changes but very few match the filtering criteria this issue can derive in a performacen problem.
1. Steps to reproduce and the simplest code sample possible to demonstrate the issue
2. What you expected to happen
The lastseq should be stored in the local checkpoint even if the changes result is empty
3. What actually happened
The lastseq is not stored whe changes are empty
Environment details
Version 2.4.0