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 include_docs=true?
Adam
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 <[email protected]>
> 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
>>
