nickva opened a new issue #3948:
URL: https://github.com/apache/couchdb/issues/3948
Noticed this error pop up when inserting large _bulk_docs batches
```
req_err(2308979097) unknown_error : badarg#012 [
<<"dict:fetch/2 L131">>,
<<"couch_util:-reorder_results/2-lc$^1/1-1-/2 L507">>,
<<"couch_util:-reorder_results/2-lc$^1/1-1-/2 L507">>,
<<"fabric_doc_update:go/3 L42">>,
<<"fabric:update_docs/3 L299">>,
<<"chttpd_db:db_req/2 L553">>,
<<"chttpd:handle_req_after_auth/2 L327">>,
<<"chttpd:process_request/1 L310">>
]
```
This error happened when the number of replies doesn't match the number of
responses when we call `couch_util:reorder_results/2`.
https://github.com/apache/couchdb/blob/e4b8a4624fc7ae09b4649aac9a8d68226208cd8b/src/fabric/src/fabric_doc_update.erl#L45
In my test I inserting 100+ design documents in a rapid succession. They had
VDUs and map views. Eventually it got a point where there were timeouts
allocating and calling `couchjs` processes. Those manifested as above `badarg`
exception and `500`.
Adding log statements, noticed two separate cases
1) None of the responses returned and `Health = ok` and `Results = []`
2) Some returned with `Health = accepted`, `length(AllDocs) = 101` and
`length(Results) = 50`
Both cases result in a `badarg`.
https://github.com/apache/couchdb/blob/e4b8a4624fc7ae09b4649aac9a8d68226208cd8b/src/couch/src/couch_util.erl#L529-L531
Here we look at the size of input docs, and if that's `>100`, we use a
dictionary. If the dict key is missing it blows up with a `badarg`. That
behavior is different than when there are `< 100` docs since
`couch_util:get_value/2` returns `undefined`. I suspect then end up with a
`201` HTTP response and each of the missing doc would have "error" :
"undefined"? But I haven't checked that far.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
