Comment 3 for bug 999574

Note that this should handle the restore-from-backup case as well. Where a db gets reverted to a previous state in time, and we use it again for a bit, then do sync and the world burns. :)

One thing we haven't specifically worked through is if the SyncTarget might notice that it is getting an invalid data stream.

Specifically, you could get put_doc_if_newer with a generation + transaction id. The generation could be older than what you have stored as the most recent generation. Or it could match, but the transaction id is different.

However, the rollback-but-not-used case would like to not have to do a full sync. So instead, you could have the logic be:

If you get a document generation that is older than what we thought was last, *and* that content would be an insert, abort. If it is a conflict, we may have treated it as a conflict the last time we saw it. If it is converged, it is the same content. If it is superseded, we probably saw it in the past and just ignored it.

So the check becomes:

1) If the generation is newer than what we have, we are happy.
2) If the generation is equal to what we have, the transaction id must match or we fail the sync.
3) If the generation is older than what we have, the content must not be newer than what we have, or we fail the sync.