Does CouchDB need a server‑side abort mechanism for cancelled _changes feeds and view queries?

The goal is to ensure that when a client cancels a request—by closing the TCP connection or exceeding a timeout—any server‑side work such as ongoing map‑reduce index updates or _changes feed processing is halted promptly to avoid wasting CPU and I/O resources.

CouchDB currently stops transmitting _changes events after detecting a closed socket, but ongoing view index updates continue until the next batch boundary. The built‑in _changes endpoint does not honor HTTP Timeout or Connection: close to abort server‑side work, and official client libraries do not propagate cancellation contexts. Behavior may differ between CouchDB 2.x and 3.x and can be masked by reverse proxies that delay socket closure detection.

• Should CouchDB introduce a server‑side abort signal (e.g., via a custom header or HTTP 499) that stops ongoing map‑reduce computations when the client disconnects?
• How should the abort mechanism interact with existing batch boundaries and the mem3 storage engine to guarantee consistency?
• What changes, if any, are required in official client libraries to propagate cancellation contexts or timeout values to the server?