[
https://issues.apache.org/jira/browse/COUCHDB-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195972#comment-13195972
]
Benoit Chesneau commented on COUCHDB-1395:
------------------------------------------
Randall: I will put a new version of the patch in the middle of the week.
I'm not sure about the delayed response thing. Shouldn't we either, have a way
to report back the errors we add at the end? Eventually closing the connection
? Like sending an {"error": ... } ? I agree that the right thing to do anyway
is sending the corrects header first.
> Not well-formed JSON in changes feed filtered by view.
> ------------------------------------------------------
>
> Key: COUCHDB-1395
> URL: https://issues.apache.org/jira/browse/COUCHDB-1395
> Project: CouchDB
> Issue Type: Bug
> Affects Versions: 1.2, 1.3
> Environment: Apache CouchDB 1.3.0a-d59cdd7-git
> Apache CouchDB 1.2.0a-0d8ddc8-git
> Reporter: Alexander Shorin
> Priority: Critical
> Attachments: filtered_view_bug.sh
>
>
> CouchDB returns invalid JSON response for _changes feed if filter view have
> failed somehow: by code mistake, bug, os timeout etc.
> Steps to reproduce:
> 1. Create db and fill it with some documents.
> 2. Create buggy view that would make view server crush for some document. For
> javascript one segfault and os timeout errors are actual due to any
> exceptions raised from map function is silenced. You view could be fine
> however for normal usage.
> 3. Request changes feed and apply this buggy view as filter.
> Story:
> View function had never proceed design documents and mostly they are created
> with that knowledge. But in changes feed they have to process every document
> in database and DDocs too, so they breaks their original logic and creates
> unexpectable situation. Another side of problem is about custom query servers
> that could prevent view processing on first occurred exception or due dynamic
> code execution nature.
> Certainly, it's all about invalid view function that generates exception for
> some document in some case, but should _changes feed return malformed data in
> this case or just notify about problem somehow and emit valid parseable JSON?
> Expected result:
> Valid JSON response and some message about document processing error.
> Actual result:
> * About to connect() to localhost port 5984 (#0)
> * Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > GET /filtered_view_bug/_changes?filter=_view&view=bug/crush_on_ddoc HTTP/1.1
> > User-Agent: curl/7.21.4 (x86_64-pc-linux-gnu) libcurl/7.21.4 GnuTLS/2.10.5
> > zlib/1.2.5
> > Host: localhost:5984
> > Accept: application/json
> >
> < HTTP/1.1 200 OK
> < Transfer-Encoding: chunked
> < Server: CouchDB/1.3.0a-d59cdd7-git (Erlang OTP/R14B04)
> < ETag: "3IV66Q7INUYEHYKVWADD0CA8A"
> < Date: Thu, 26 Jan 2012 19:30:23 GMT
> < Content-Type: application/json
> < Cache-Control: must-revalidate
> <
> {"results":[
> {"seq":1,"id":"foo","changes":[{"rev":"1-5277061607e266deb7cc87eb63354db7"}]},
> {"seq":2,"id":"bar","changes":[{"rev":"1-ced1ed0168f00311e1ee301cda904840"}]},
> {"seq":3,"id":"baz","changes":[{"rev":"1-ae16db0d925a8295009ff580e226a978"}]}
> * Received problem 2 in the chunky parser
> * Closing connection #0
> curl: (56) Received problem 2 in the chunky parser
> Last chunk arrives with "HTTP/1.1 500 Internal Server Error" instead of size
> value.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
