`httpd.timeout` in CouchDB 3.2.0 `_changes` long-poll boundary

Answer first

Each _changes long-poll is an independent HTTP request with its own per-connection wait boundary. Multiple simultaneous feeds on one node do not share or reset each other's timer. The node will track sockets, memory and CPU per feed, so OS file-descriptor and connection limits are usually hit before any per-feed timeout becomes the bottleneck.

HTTP pipelining cannot extend a blocking long-poll wait. The connection is held until CouchDB responds, so queued pipelined requests are head-of-line blocked and do not make the server wait longer. An intermediate proxy or load balancer can only terminate, buffer or reconnect the feed; it adds its own idle timeout and may return 504/502 or close the connection earlier than CouchDB. It does not make CouchDB wait longer.

If httpd.timeout is set to 0, newly established long-poll sessions after a reload/restart can wait indefinitely for a change, subject to the _changes timeout query parameter and any proxy/TCP idle limits. Sessions that were already open under the previous limit typically keep the deadline they were created with and will close at that deadline or on reconnect. Behavior on a live reload is version-specific.

Likely explanation vs confirmed facts

What is confirmed

• CouchDB _changes supports feed=longpoll with a client-supplied timeout parameter, and continuous/eventsource feeds with heartbeat. The effective wait is the earlier of server socket idle, feed timeout parameter, proxy idle timeout, and TCP/TLS keepalive.
• Feeds are per-connection. Activity on one feed does not extend another feed's timeout.

What is uncertain for 3.2.0

• There is no verified CouchDB 3.2.0 documentation confirming an [httpd] timeout integer that replaces a fixed 30-second HTTP request limit, nor a confirmed default value. The 30-second replacement claim in the prompt is an assumption and must be verified against the installed build.
• Whether timeout=0 truly disables the server-side wait limit, and whether a running node applies the change to already-open connections without restart/reconnect, is build-specific.

Steps needed for this case

1. Verify the setting exists and is effective. Check the resolved config:

   curl -s http://localhost:5984/_node/_local/_config/httpd/timeout

   Inspect default.ini and local.ini under [httpd] and confirm the key is accepted by your build.
2. Measure per-connection independence. Open several long-poll requests with no changes and time them:

   curl -v "http://localhost:5984/db/_changes?feed=longpoll&timeout=60000"

   Repeat with concurrent curls. Each should close independently.
3. Test proxy impact. Run the same request through the intended proxy/load balancer and compare client-observed close time with CouchDB access logs. Look for proxy 504 or idle close before CouchDB's boundary.
4. If you change httpd.timeout to 0, reload/restart and open a new long-poll session with no pending change. Confirm it stays open beyond the prior default only after reconnect, and monitor open file descriptors and memory under concurrent feeds.

Operational note: uniform indefinite waiting retains slow clients but can exhaust connections, file descriptors and memory under load. Prefer a finite _changes timeout with heartbeat for continuous feeds rather than relying on httpd.timeout=0.

One missing diagnostic that changes the recommendation: the resolved CouchDB build and the effective [httpd] timeout value in your deployment. If the key is absent or ignored in your build, the whole timeout interaction described above does not apply.