[
https://issues.apache.org/jira/browse/COUCHDB-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15470764#comment-15470764
]
Samuel Tardieu commented on COUCHDB-3133:
-----------------------------------------
I understand. However, another error path necessarily exists if the shard
answers with an error as "200 OK" is sent after the heartbeat timeout. Why have
two different mechanism?
To make sure I am clear on this:
% curl -v
http://localhost:5984/test/_changes?feed=continuous&since=now&heartbeat=1000
gives an error such as "500" if an error happens before 1 second, and gives
"200" then signals the error differently (how?) if the error happens after 1
second.
This looks a bit odd.
> Continuous change response header is sent late
> ----------------------------------------------
>
> Key: COUCHDB-3133
> URL: https://issues.apache.org/jira/browse/COUCHDB-3133
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
> Affects Versions: 2.0.0
> Reporter: Samuel Tardieu
>
> In CouchDB 1.x, when connecting to the continuous change stream, the "200 OK"
> was sent as soon as the connection was established.
> This was very useful when using a connection pool to ensure, for example,
> that all the "_changes" stream were established before starting manipulating
> the database, so that we would be notified of any interesting event happening.
> However, in CouchDB 2.0.0-RC4 the "200 OK" is sent only after the first
> change is available. More precisely, when using a filter, it is sent after
> the first time the filter is invoked, be it successful or not.
> This prevents a client from knowing whether it is indeed connected to the
> changes stream or not yet. This is a functional regression against 1.x.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
