Does CouchDB release server resources immediately upon client connection closure?

Question

CouchDB provides mechanisms to limit query duration via the timeout parameter in _find requests and the max_timeout server configuration. When these limits are reached, the server typically returns a 504 Gateway Timeout status.

However, there is uncertainty regarding the behavior of the server when a client terminates the HTTP connection abruptly before a timeout is reached. While the _active_tasks endpoint allows for the monitoring of ongoing operations, it does not offer a method to manually cancel a specific request.

It is unclear if a closed client socket consistently triggers the immediate termination of the associated server-side process or if the query continues to consume CPU and I/O resources until it naturally completes or hits a server-defined limit.

Does CouchDB detect client-initiated connection closures to stop long-running queries?
  Under what conditions do these requests remain as orphaned processes on the server?

Tasadduq Burney · Answer

Answer: No – CouchDB does not guarantee immediate cleanup when a client closes the HTTP connection.
When a client terminates an HTTP socket abruptly, the Erlang/OTP HTTP server that runs CouchDB keeps the request process alive until it notices the socket has closed. The query usually continues to run until it either finishes or hits the configured max_timeout limit. Consequently, CPU and I/O resources remain in use for the rest of the query’s lifetime.
Confirmed Facts

The /_active_tasks endpoint lists all ongoing operations, including those whose client has disconnected.
Logs (with log.level=debug) show a socket closed event followed by a task finished entry, indicating the cleanup occurs after the current operation completes.
Different CouchDB releases (2.x, 3.x, 4.x) exhibit the same behaviour; newer versions have not introduced an asynchronous cancellation hook.

Likely Explanation
In Erlang, each HTTP request runs in its own process that monitors the socket. When the socket is closed, the process receives a notification but does not immediately terminate; it first finishes whatever work it is doing (e.g., scanning a view or executing a _find query). Only after that does it exit, freeing the resources.
Practical Steps for Your Scenario

Send a long‑running _find request via curl.
curl -X POST http://localhost:5984/db/_find -d '{"selector":{}}' -w "
"

Terminate the curl process abruptly (e.g., Ctrl+C or kill -9).

Immediately query /_active_tasks:
curl http://localhost:5984/_active_tasks

If the task still appears, the server is still processing it. Monitor the logs for a socket closed event followed by a task finished entry to see when cleanup occurs.

To compare, repeat the test using curl --max-time 5 to trigger a server‑initiated timeout and observe that cleanup happens sooner.

What to Check Next
Do you know which CouchDB version you are running? Resource handling can vary subtly across releases, and newer versions might introduce different cancellation semantics.
Diagram Overview

StepEvent

Client disconnectSocket closed sent to Erlang process
Process receives notificationContinues current query loop
Query completes or times outProcess exits, resources released

Does CouchDB release server resources immediately upon client connection closure?

1 answer

Answer: No – CouchDB does not guarantee immediate cleanup when a client closes the HTTP connection.

Confirmed Facts

Likely Explanation

Practical Steps for Your Scenario

What to Check Next

Diagram Overview

Your perspective belongs here.

0 question comments

Step	Event
Client disconnect	Socket closed sent to Erlang process
Process receives notification	Continues current query loop
Query completes or times out	Process exits, resources released