Update simultaneous open connections docs for slot-release-on-headers

The Workers runtime now releases connection slots when response headers
arrive, rather than when the response body is fully consumed. This means
the 6-connection limit only constrains how many connections can be in
the 'waiting for headers' phase simultaneously.

Remove documentation of stall detection and forced connection
cancellation (Response closed due to connection limit), as this
behavior is no longer observable with the new slot release timing.
Keep the response.body.cancel() advice for memory management.

Add a changelog entry for the change.

Author: harrishancock

src/content/changelog/workers/2026-04-09-relaxed-connection-limiting.mdx

@@ -0,0 +1,9 @@
+---
+title: Relaxed simultaneous connection limiting
+description: The six-connection limit now only applies while waiting for response headers, allowing Workers to maintain more open connections simultaneously.
+date: 2026-04-09
+---
+
+The [simultaneous open connections limit](/workers/platform/limits/#simultaneous-open-connections) has been relaxed. Previously, each Worker invocation was limited to six open connections at a time for the entire lifetime of each connection, including while reading the response body. Now, a connection slot is freed as soon as response headers arrive, so the six-connection limit only constrains how many connections can be in the initial "waiting for headers" phase simultaneously.
+
+This means Workers can now have many more connections open at the same time without queueing, as long as no more than six are waiting for their initial response. This eliminates the `Response closed due to connection limit` exception that could previously occur when the runtime canceled stalled connections to prevent deadlocks.

src/content/docs/workers/platform/limits.mdx

@@ -200,7 +200,7 @@ Using global [`fetch()`](/workers/runtime-apis/fetch/) to call another Worker on
 
 ## Simultaneous open connections
 
-Each Worker invocation can open up to six simultaneous connections. The following API calls count toward this limit:
+Each Worker invocation can have up to six connections simultaneously waiting for response headers. The following API calls count toward this limit while the initial connection is being established and the server has not yet responded:
 
 - `fetch()` method of the [Fetch API](/workers/runtime-apis/fetch/)
 - `get()`, `put()`, `list()`, and `delete()` methods of [Workers KV namespace objects](/kv/api/)
@@ -211,9 +211,9 @@ Each Worker invocation can open up to six simultaneous connections. The followin
 
 Outbound WebSocket connections also count toward this limit.
 
-Once six connections are open, the runtime queues additional attempts until an existing connection closes. The runtime may close stalled connections (those not actively reading or writing) with a `Response closed due to connection limit` exception.
+Once response headers arrive for a connection, it no longer counts toward the six-connection limit. This means a Worker can have many connections open simultaneously, as long as no more than six are in the initial "waiting for headers" phase at the same time. If a seventh connection is attempted while six are already waiting for headers, it is queued until one of the existing connections receives its response headers.
 
-If you use `fetch()` but do not need the response body, call `response.body.cancel()` to free the connection:
+If you use `fetch()` but do not need the response body, calling `response.body.cancel()` is still good practice to free memory:
 
 ```ts
 const response = await fetch(url);
@@ -227,8 +227,6 @@ if (response.statusCode <= 299) {
 }
 ```
 
-If the system detects a deadlock (pending connection attempts with no in-progress reads or writes), it cancels the least-recently-used connection to unblock the Worker.
-
 :::note
 
 The runtime measures simultaneous open connections from the top-level request. Workers triggered via [Service bindings](/workers/runtime-apis/bindings/service-bindings/) share the same connection limit.