[ 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