Deletions of empty documents are not imported

Something of an edge case, but consider the use case of "marker" documents, i.e. documents with no data inside them, where the existence of a certain key is used as a lightweight indicator of something.

For Sync Gateway to be able to handle these, they would have to be JSON objects, so the minimum is {}.

If such as document is later deleted by an SDK or TTL, that deletion is not imported, and SG continues to report the document at its previous revision.

• CBL / SG Version: SG 2.7
• SG Config:

  {

  "databases": {

  "db": {

  "bucket": "test",

  "enable_shared_bucket_access": true,

  "import_docs": true,

  "password": "password",

  "server": "http://localhost:8091",

  "username": "Administrator",

  "num_index_replicas": 0,

  "users": {

  "GUEST": {"admin_channels": ["*"], "disabled": false}

  },

  "sync": `function(doc) {

  expiry(10)

  }`,

  }

  },

  "logging": {

  "console": {

  "enabled": true,

  "log_level": "debug",

  "log_keys": ["*"],

  "color_enabled": true

  }

  }

  }

• Steps to Reproduce:

  # Put an empty document:

  curl localhost:4984/db/test_doc -X PUT -d '{}' -H 'Content-type: application/json'

  # Wait until the TTL has passed

  sleep 11

  # GET with no rev to trigger KV GET -> lazy expiry -> on demand import

  curl localhost:4984/db/test_doc

Alternative - ruling out the on demand import:

# Put an empty document:

curl localhost:4984/db/test_doc -X PUT -d '{}' -H 'Content-type: application/json'

# Manually delete the doc

cbc rm -U couchbase://localhost/test -u Administrator -P jflath test_doc

# GET to see current rev

curl localhost:4984/db/test_doc

• Actual Result:

Document remains at revision 1 (1-ca9ad22802b66f662ff171f226211d5c to be exact - should always be the same )
Clients are not notified that this is deleted, but will see it suddenly purged one the metadata purge interval rolls by.

• Expected Result:

Deletion should be imported, bumping this to rev 2.

—

I suspect this is down to an edgecase in the CRC32 checking, where to calculate the CRC32 of the completely empty body in the deletion, we take an empty struct and marshall it into JSON, leaving us with {}. This matches what we had in rev 1, even though it's not a "true" representation of the zero-length body in the mutation.