We have an application that continuously recycles document IDs. For example the recycling works like this:
Client creates a document of id Foo
A service listening on the sync gateway _changes feed picks the change to document foo and does some work
Once the service has completed the work for Foo it deletes the document Foo
Client again creates document Foo and the cycle repeates
This doesn’t happen all that often but the concern I have and have seen in testing is once the client has pruned the revision history for Foo it will create the document again with sequence ID 1-xxxx while the server is at 1100-xxx
What is the expected behavior from the Sync Gateway and CBL? Will the Sync Gateway be OK with getting a seq rev of 1 again? What gets returned to CBL when the server deletes the Foo document (seq 2 or 1101)?
That shouldn’t happen; when the client prunes it will keep the latest 20 revisions including the latest ‘tombstone’ (deletion revision), so when it re-creates the doc it will add the new revision after the tombstone. Do you have any more information about the circumstances where this happens?
If the client does create a new live revision with ID 1-xxxx, it will take precedence over any tombstone, so it becomes the current revision as expected. I don’t think this will cause problems.
Is it necessary for the server-side worker to delete the document at all?
How we were able to get it into this state was by accident but here is the steps we did. I’ve been able to reproduce it a few times now.
Allow the document with the same ID to be created and deleted more times than the revs_limit on the sync gateway (in our setup the default 1000 is set). In the test we have we are just doing it 1200 times
wipe out the client CBL database
connect the client and attempt to create the document using the same ID. In this case the document seq # will be 1-xyz however the server will have 1200-xyz
If the document seq count is less than revs_limit on the sync gateway it looks like the rev meta data for the deleted document is sync’ed but when it’s over revs_limit I’m not seeing the meta data in the CBL database.
We are currently using Sync Gateway 1.4.0 and CBL 1.4.0, I haven’t tried with 1.4.1 sync gateway as of yet but will do that soon.
On the server side we don’t really need to delete the document, we were doing it to save space on the client but we could change is to have a simple status and remove the rest of document contents. Then the footprint on the client should be small.
I was more curious on what the expected behavior was and if what we were doing would be safe to continue.
If possible, it would be preferable to go with the suggested approach of updating the doc instead of deletion/ re-creating the document.
W.r.t your question :
When the client reconnects, it should sync up with the gateway and fetch the missing revisions including the tombstoned/deleted revision 1200 . The revs_limit determines what metadata gets pruned on the sync gateway. In your test, this means that metadata for revisions 1000-1200 should be retained on the server. The revs_limit shouldn’t affect whether or not the deleted revision gets synched to the client. Now, since the client created a new revision 1-xxx, that will become the new current revision because 1200 was a tombstone revision.