A technical co-founder of Cloudant agreed that this was a bug when I first hit
it a few years ago. I found back the original thread here — this is the
discussion I was trying to recall in my OP:
https://twitter.com/mlmilleratmit/status/410911219428491265
It sounds like perhaps there is a related issue tracked internally at Cloudant
as a result of that conversation.
JamesM, thanks for your support here and tracking this down. 203 seemed like
the best status code to "steal" for this to me too. Best wishes in getting this
fixed!
regards,
-natevw
On Mar 25, 2015, at 4:49 AM, Robert Newson <rnew...@apache.org> wrote:
> 2.0 is explicitly an AP system, the behaviour you describe is not classified
> as a bug.
>
> Anti-entropy is the main reason that you cannot get strong consistency from
> the system, it will transform "failed" writes (those that succeeded on one
> node but fewer than R nodes) into success (N copies) as long as the nodes
> have enough healthy uptime.
>
> True of cloudant and 2.0.
>
> Sent from my iPhone
>
>> On 24 Mar 2015, at 15:14, Mutton, James <jmut...@akamai.com> wrote:
>>
>> Funny you should mention it. I drafted an email in early February to queue
>> up the same discussion whenever I could get involved again (which I promptly
>> forgot about). What happens currently in 2.0 appears unchanged from earlier
>> versions. When R is not satisfied in fabric, fabric_doc_open:handle_message
>> eventually responds with a {stop, …} but leaves the acc-state as the
>> original r_not_met which triggers a read_repair from the response handler.
>> read_repair results in an {ok, …} with the only doc available, because no
>> other docs are in the list. The final doc returned to
>> chttpd_db:couch_doc_open and thusly to chttpd_db:db_doc_req is simply {ok,
>> Doc}, which has now lost the fact that the answer was not complete.
>>
>> This seems straightforward to fix by a change in
>> fabric_open_doc:handle_response and read_repair. handle_response knows
>> whether it has R met and could pass that forward, or allow read-repair to
>> pass it forward if read_repair is able to satisfy acc.r. I can’t speak for
>> community interest in the behavior of sending a 202, but it’s something I’d
>> definitely like for the same reasons you cite. Plus it just seems
>> disconnected to do it on writes but not reads.
>>
>> Cheers,
>> </JamesM>
>>
>>> On Mar 24, 2015, at 14:06, Nathan Vander Wilt <nate-li...@calftrail.com>
>>> wrote:
>>>
>>> Sorry, I have not been following CouchDB 2.0 roadmap but I was extending my
>>> fermata-couchdb plugin today and realized that perhaps the Apache release
>>> of BigCouch as CouchDB 2.0 might provide an opportunity to fix a serious
>>> issue I had using Cloudant's implementation.
>>>
>>> See https://github.com/cloudant/bigcouch/issues/55#issuecomment-30186518
>>> for some additional background/explanation, but my understanding is that
>>> Cloudant for all practical purposes ignores the read durability parameter.
>>> So you can write with ?w=N to attempt some level of quorum, and get a 202
>>> back if that quorum is unment. _However_ when you ?r=N it really doesn't
>>> matter if only <N nodes are available…if even just a single available node
>>> has some version of the requested document you will get a successful
>>> response (!).
>>>
>>> So in practice, there's no way to actually use the quasi-Dynamo features to
>>> dynamically _choose_ between consistency or availability — when it comes
>>> time to read back a consistent result, BigCouch instead just always gives
>>> you availability* regardless of what a given request actually needs. (In my
>>> usage I ended up treating a 202 write as a 500, rather than proceeding with
>>> no way of ever knowing whether a write did NOT ACTUALLY conflict or just
>>> hadn't YET because $who_knows_how_many nodes were still down…)
>>>
>>> IIRC, this was both confirmed and acknowledged as a serious bug by a
>>> Cloudant engineer (or support personnel at least) but could not be quickly
>>> fixed as it could introduce backwards-compatibility concerns. So…
>>>
>>> Is CouchDB 2.0 already breaking backwards compatibility with BigCouch? If
>>> true, could this read durability issue now be fixed during the merge?
>>>
>>> thanks,
>>> -natevw
>>>
>>>
>>>
>>>
>>>
>>> * DISCLAIMER: this statement has not been endorsed by actual uptime of
>>> *any* Couch fork…
>>
