Document query_response option about couchdb-documentation

[denyeart]

We see the same intermittent problem in CouchDB 3.1.0 (single node). _all_docs requests are returning fine (1000 records each in about 300ms) and then all of a sudden we get a 200 aborted on the next similar query after about 5 seconds:

[notice] 2020-10-17T07:22:18.239062Z nonode@nohost <0.24353.1500> d1c70dc3f1 couchdb-peer0-org1:5984 172.30.188.173 user GET /testorgschannel0_mapcc$$hcollection$simple/_all_docs?attachments=true&include_docs=true&inclusive_end=false&limit=1001&startkey=%22l%2Bxj9Mibwp%2F%2FQ9ZWKb49wURav%2FV7Qll4YkWogbSwhrQ%3D%22 200 aborted 5219
[error] 2020-10-17T07:22:18.239114Z nonode@nohost <0.24353.1500> d1c70dc3f1 Response abnormally terminated: timeout

A second later another query fails with a different error:

[error] 2020-10-17T07:22:19.131115Z nonode@nohost <0.15619.1999> 39d3b723e2 req_err(1577439538) internal_server_error : No DB shards could be opened.
    [<<"fabric_util:get_shard/4 L111">>,<<"fabric_util:get_shard/4 L128">>,<<"fabric_util:get_shard/4 L128">>,<<"fabric:get_security/2 L183">>,<<"chttpd_auth_request:db_authorization_check/1 L110">>,<<"chttpd_auth_request:authorize_request/1 L19">>,<<"chttpd:handle_req_after_auth/2 L321">>,<<"chttpd:process_request/1 L306">>]

And then subsequent queries are fine again.

I agree that CouchDB should not return a 200 status for an error response.

[denyeart]

After a discussion on CouchDB slack, it appears that there is a new api option ?buffer_response=true on view queries in v3.1.1 that ensures that the response is complete before returning back a 200. If not set the default is for the response to be streaming in which case a 200 is returned even while the response is streaming back (and may eventually abort). Given the new enhancement, I think we could close this issue (although would be good to get the API docs updated to describe this behavior).

[wohali]

FYI this is also available as a server-wide configuration, [chttpd] buffer_response.