Problem: CouchDB not answering to request

[topse]

Hi, I have a strange behaviour with CouchDB-Server (latest Version) and I don't have more ideas what may be the problem.

I am creating an "CouchDB-Connector" in Flutter. When the connector is logged in, it automatically notifies "http://yxz:5984/_db_updates?feed=continuous&since=now" to be informed about created and deleted databases.

I wrote lots of unit tests for all kinds of use cases of the new library. The Test begins with setting up a Couch-Connector which is alive the whole time and mostly used for testing. But for some testcases a temporal second connector is created and logged in. When done, everything is logged out.

Mostly this works fine. Some days ago I added another Test-Case which needed a temporal second connector, but this time the notification to "_db_updates" fails.

I used Wireshark to check out the messages which are sent between my application and CouchDB and I that is where my question starts.

1. Messages when everything works as expected

App->CouchDB    GET /_db_updates?feed=continuous&since=now
CouchDB->App    ACK (TCP)
CouchDB->App    HTTP-Data with Response Header
CouchDB->App    Updates with JSON Objects

2. Messages when failing to connect:

App->CouchDB    GET /_db_updates?feed=continuous&since=now
CouchDB->App    ACK (TCP)
thats all... not Response Header.

I don't know what may be going wrong and would appreciate any help, where I may could find a log in CouchDB or so.

BTW, I am running CouchDB in docker, and 'docker logs' gave the following:

-- My Application says "send GET /_db_updates?feed=continuous&since=now" --
-- Couch shows in log:  [notice] 2025-08-03T15:48:13.799335Z nonode@nohost <0.1880.0> 44fd166795 localhost:5984 172.17.0.1 undefined POST /_session 200 ok 1

This "undefined POST" seems to be very often at that position, but I think it is accidently? That would mean, that CouchDB does not give any log regarding the Request?

I would appreciate any hint.

Best Regards,
Tobias

[topse]

In the meantime I tried to get more logs...

Here a log (combined of my application and CouchDB) of a "working example":

CouchConn INFO: 2025-08-04 12:33:53.965785: Login as admin success... starting subscriptionMgr...
SubscriptionManager INFO: 2025-08-04 12:33:53.966418: Subscribing to _db_updates stream. This will notify about database creation and deletion.
COUCHDB INFO: 2025-08-04 12:33:53.967828: [notice] 2025-08-04T10:33:53.940638Z nonode@nohost <0.431.0> 62a7bc7c1a localhost:5984 172.17.0.1 undefined POST /_session 200 ok 3
COUCHDB INFO: 2025-08-04 12:33:53.970363: [debug] 2025-08-04T10:33:53.969708Z nonode@nohost <0.432.0> ae9ba5085d no record of user admin
COUCHDB INFO: 2025-08-04 12:33:53.970363: [debug] 2025-08-04T10:33:53.969739Z nonode@nohost <0.432.0> ae9ba5085d timeout 600
COUCHDB INFO: 2025-08-04 12:33:53.970363: [debug] 2025-08-04T10:33:53.969800Z nonode@nohost <0.432.0> ae9ba5085d Successful cookie auth as: "admin"
SubscriptionManager FINE: 2025-08-04 12:33:54.228668: _db_updates  statuscode: 200

Interesting seems to be, the "undefined POST _session" - log from CouchDB. I think this is related to the login-try? This log is after my application has received the Status 200 of the login-procedure.

The last message shows that the response header has been received with status 200.

Here is the "not-working-example":

CouchConn INFO: 2025-08-04 12:34:03.848612: Login as admin success... starting subscriptionMgr...
SubscriptionManager INFO: 2025-08-04 12:34:03.848671: Subscribing to _db_updates stream. This will notify about database creation and deletion.
COUCHDB INFO: 2025-08-04 12:34:03.848960: [debug] 2025-08-04T10:34:03.846659Z nonode@nohost <0.1875.0> 3e6071b7d4 no record of user admin
COUCHDB INFO: 2025-08-04 12:34:03.848960: [notice] 2025-08-04T10:34:03.847058Z nonode@nohost <0.1875.0> 3e6071b7d4 localhost:5984 172.17.0.1 undefined POST /_session 200 ok 1
COUCHDB INFO: 2025-08-04 12:34:03.850898: [debug] 2025-08-04T10:34:03.849932Z nonode@nohost <0.1890.0> beff03c158 no record of user admin
COUCHDB INFO: 2025-08-04 12:34:03.850898: [debug] 2025-08-04T10:34:03.849951Z nonode@nohost <0.1890.0> beff03c158 timeout 600
COUCHDB INFO: 2025-08-04 12:34:03.850898: [debug] 2025-08-04T10:34:03.849981Z nonode@nohost <0.1890.0> beff03c158 Successful cookie auth as: "admin"
COUCHDB INFO: 2025-08-04 12:34:08.136219: [notice] 2025-08-04T10:34:08.133189Z nonode@nohost <0.365.0> -------- rexi_server : cluster stable
COUCHDB INFO: 2025-08-04 12:34:08.136219: [notice] 2025-08-04T10:34:08.133281Z nonode@nohost <0.369.0> -------- rexi_buffer : cluster stable

Same behaviour as before regarding the timing of the "POST-log" -- but no Response Header sent??

I would really appreciate if anyone has a clou what could go wrong.

Best Regards,
Tobias

[rnewson]

/_db_updates?feed=continuous&since=now will not start the http response until there is a new change. So your "not working" examples coincide with a time where no databases are being created/deleted/updated.

[topse]

You are a lifesaver... thanks!

Best Regards,
Tobias

PS: Is this an oversight of me? Do I find that information somewhere in the documentation? If yes -- then sorry!

[rnewson]

No, I don't think it's an oversight on your part, we don't document when couchdb starts the response (we tend to delay it until we can confirm if we should send a 200 OK or some kind of error). You just need to anticipate that the request might time out without a response if there are no changes. Arguably we should change the behaviour to start a response promptly, even if the response body ultimately ends up with no results.

[nickva]

It's possible to get the request to start earlier if you also use heartbeats. Then the delay until the response start will be no longer than one heartbeat.

% curl -v -N http://adm:pass@localhost:15984/_db_updates'?feed=continuous&since=now&heartbeat=10000'
> User-Agent: curl/8.7.1
...
* Request completely sent off

# waiting ....10 seconds

< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
<

I added the (#waiting... 10 seconds in the there)

[topse]

Hi,
to be honest this feels like a bug for me. Lets say it in other words:

I am a nice application guy sending a nice and well-formed request to some server guy -- and he just ignores me? That is not very polite. He could at least confirm that he heard me, even if he has nothing special to say at the moment... just silence could also mean, something went wrong.

So +1 for changing (or should I say correcting) this behaviour.

Best Regards,
Tobias