couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: include_docs returning doc=null
Date Fri, 19 Feb 2010 15:18:50 GMT
Indeed we did.  One of our customers bumped into a similar failure mode the other day too.
 In his case the doc member returned was {error, missing}, which pretty much completely baffles
me.  Mark's example is also baffling because it does not use stale=ok, so _any_ error opening
the document is troubling.

We have code in couch_view_group that ostensibly prevents the view index header from being
saved if the DB committed_update_seq is still behind it.  We do that precisely to prevent
this situation from happening.  We should also make it so that the version of the DB used
to satisfy the include_docs request is the same MVCC snapshot used by the view group.  I think
we already do.

I guess another alternative to a logic error in couch_view_group is in-flight corruption.
 If the MD5 checksum of what we read back from disk doesn't match the stored MD5 we do throw(file_corruption).
 But the catch statement in that pasted code hides the error condition from the client.  I'm
definitely +1 on an {error, Reason} tuple there.  That call should never fail.

Mark, is it fully reproducible?  You can always read the document directly, but never through


On Feb 19, 2010, at 8:14 AM, Paul Davis wrote:

> I'd be +1 returning an error. In fact we used to IIRC.
> Paul
> On Thu, Feb 18, 2010 at 10:29 PM, Mark Hammond <> wrote:
>> I've struck a rare case where a view request with include_docs=true (but no
>> stale=ok and no custom _id emitted from the view) is returning a row with
>> doc=null.
>> I guess is might be possible for a document to be deleted between the view
>> row being processed and the doc being opened for the view result but I don't
>> think this is happening here - the view also emits the document _rev, and
>> directly after getting doc=null I can open the specified document in futon
>> and it has the same _rev as the view row. Unfortunately, couch is not
>> offering any clues about what the problem is.
>> I tracked the code returning null to couch_httpd_view:doc_member - it does:
>>    case (catch couch_httpd_db:couch_doc_open(Db, DocId, Rev, [])) of
>>        #doc{} = Doc ->
>>            JsonDoc = couch_doc:to_json_obj(Doc, []),
>>            [{doc, JsonDoc}];
>>        _Else ->
>>            [{doc, null}]
>> So should the doc fail to open for any reason, you just get a null and the
>> reason for the failure is discarded.  Is this by intent?  ISTM it would be
>> better to instead, or also, provide an {error, Reason} element in the view
>> row.
>> Does this sound desirable?  If so, should an error still leave a doc=null
>> element, or only include the error element?  Let me know and I'll open a but
>> and submit a patch...
>> Cheers,
>> Mark

View raw message