Curious API corner case when re-creating deleted documents

[Paul Davis <pa...@gmail.com>]

Hey all,

We had a customer get tripped up on a fairly obscure part of the API
today and I thought I'd ask the community if we shouldn't tweak things
lightly.

The basic setup was that a user accidentally deleted a doc and then
went through the steps to recreate it. It all worked fine except the
actual recreation threw an conflict error even though the user
specified the "correct" revision of the deleted doc (ie, the revision
that marked it as deleted rather than the revision of the body they
used to restore).

The issue here was that when we last changed revision tree merging in
couch_db_updater we expressly tightened a check when recreating
deleted documents to require that it have a _rev value at the root of
the tree. (ie, no revision specified and had one auto-generated by
couch). The reason for this was that there were cases when people
specified internal revisions (ie, non leaf revisions) which CouchDB
happily accepted and extended which created branches where there
weren't any previously.

I asked Robert Newson his thoughts and he leaned toward the current
behavior being correct where I'm thinking that we should allow the
extension. Given the disagreement I figured the mailing list would be
the best place to ask what others though would be best given that its
all a bit subtle.

For the record, Bob's point was that by requiring the rev be absent
when creating (or re-creating) a doc directly delineates
(re-)?creation from update. I on the other hand know that even though
no revision is specified it will still create a revision based on the
deleted revision so the response you get back might look surprising
when it doesn't start with "1-" which clearly indicates is using old
history when re-creating the doc.

Here's a link to a gist that shows the corner case towards the bottom.
I'll also paste it below for future people that live in a sad
post-gist world.

https://gist.github.com/davisp/8484f2a8187dd214cae0fcde4d0c2440

Paul

N.B. acurl is basically just an alias to "curl -u davisp"

$ acurl 'https://davisp.cloudant.com/test-db/_all_docs?keys=["foo"]' |
python -m json.tool
{
    "rows": [
        {
            "id": "foo",
            "key": "foo",
            "value": {
                "deleted": true,
                "rev": "2-eec205a9d413992850a6e32678485900"
            }
        }
    ],
    "total_rows": 7
}
$ acurl 'https://davisp.cloudant.com/test-db/foo?rev=2-eec205a9d413992850a6e32678485900&revs=true'
| python -m json.tool
{
    "_deleted": true,
    "_id": "foo",
    "_rev": "2-eec205a9d413992850a6e32678485900",
    "_revisions": {
        "ids": [
            "eec205a9d413992850a6e32678485900",
            "967a00dff5e02add41819138abb3284d"
        ],
        "start": 2
    }
}
$ acurl https://davisp.cloudant.com/test-db/foo?rev=1-967a00dff5e02add41819138abb3284d
| python -m json.tool
{
    "error": "not_found",
    "reason": "missing"
}
$ # A curious corner case
$ cat foo.json
{
    "_id": "foo",
    "_rev": "2-eec205a9d413992850a6e32678485900",
    "stuff": "bar"
}
$ acurl -X PUT https://davisp.cloudant.com/test-db/foo -d @foo.json |
python -m json.tool
{
    "error": "conflict",
    "reason": "Document update conflict."
}