{"id":372,"date":"2026-04-09T00:00:00","date_gmt":"2026-04-09T00:00:00","guid":{"rendered":"https:\/\/wordpress.securinsight.ca\/index.php\/2026\/04\/09\/workers-relaxed-simultaneous-connection-limiting-for-workers-4\/"},"modified":"2026-04-09T00:00:00","modified_gmt":"2026-04-09T00:00:00","slug":"workers-relaxed-simultaneous-connection-limiting-for-workers-4","status":"publish","type":"post","link":"https:\/\/wordpress.securinsight.ca\/index.php\/2026\/04\/09\/workers-relaxed-simultaneous-connection-limiting-for-workers-4\/","title":{"rendered":"Workers &#8211; Relaxed simultaneous connection limiting for Workers"},"content":{"rendered":"<p>The <a href=\"https:\/\/developers.cloudflare.com\/workers\/platform\/limits\/#simultaneous-open-connections\">simultaneous open connections limit<\/a> 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 is freed as soon as response headers arrive, so the six-connection limit only constrains how many connections can be in the initial &#8220;waiting for headers&#8221; phase simultaneously.<\/p>\n<h4>Before: New connections are blocked until an earlier connection fully completes<\/h4>\n<p><img decoding=\"async\" src=\"https:\/\/developers.cloudflare.com\/_astro\/connection-limit-before.DA5Xnf2k_Z15lWkB.svg\" alt=\"A 7th fetch is queued until an earlier connection fully completes, including reading its entire response body\" \/><\/p>\n<h4>After: New connections can start as soon as response headers arrive<\/h4>\n<p><img decoding=\"async\" src=\"https:\/\/developers.cloudflare.com\/_astro\/connection-limit-after.BnN2EWxG_Z15lWkB.svg\" alt=\"A 7th fetch starts as soon as any earlier connection receives its response headers\" \/><\/p>\n<p>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 <code>Response closed due to connection limit<\/code> exception that could previously occur when the runtime canceled stalled connections to prevent deadlocks.<\/p>\n<p>Previously, the runtime used a deadlock avoidance algorithm that watched each open connection for I\/O activity. If all six connections appeared idle \u2014 even momentarily \u2014 the runtime would cancel the least-recently-used connection to make room for new requests. In practice, this heuristic was fragile. For example, when a response used <code>Content-Encoding: gzip<\/code>, the runtime&#8217;s internal decompression created brief gaps between read and write operations. During these gaps, the connection appeared stalled despite being actively read by the Worker. If multiple connections hit these gaps at the same time, the runtime could spuriously cancel a connection that was working correctly. By only counting connections during the waiting-for-headers phase \u2014 where the runtime is fully in control and there is no ambiguity about whether the connection is active \u2014 this class of bug is eliminated entirely.<\/p>\n<h4>Before: Connections could be canceled during brief internal pauses<\/h4>\n<p><img decoding=\"async\" src=\"https:\/\/developers.cloudflare.com\/_astro\/connection-cancel-before.B6J6v5SX_ZdXLqG.svg\" alt=\"A connection with gaps from gzip decompression appears idle and is canceled by the runtime\" \/><\/p>\n<h4>After: Connections complete normally regardless of internal pauses<\/h4>\n<p><img decoding=\"async\" src=\"https:\/\/developers.cloudflare.com\/_astro\/connection-cancel-after.0sUzrfMs_2fzdYj.svg\" alt=\"The same connection completes normally because the body phase is no longer counted against the limit\" \/><\/p>","protected":false},"excerpt":{"rendered":"<p>The simultaneous open connections limit 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 is freed as soon as response headers arrive, so the six-connection limit only constrains how many connections can [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-372","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/wordpress.securinsight.ca\/index.php\/wp-json\/wp\/v2\/posts\/372","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.securinsight.ca\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wordpress.securinsight.ca\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.securinsight.ca\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.securinsight.ca\/index.php\/wp-json\/wp\/v2\/comments?post=372"}],"version-history":[{"count":0,"href":"https:\/\/wordpress.securinsight.ca\/index.php\/wp-json\/wp\/v2\/posts\/372\/revisions"}],"wp:attachment":[{"href":"https:\/\/wordpress.securinsight.ca\/index.php\/wp-json\/wp\/v2\/media?parent=372"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.securinsight.ca\/index.php\/wp-json\/wp\/v2\/categories?post=372"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.securinsight.ca\/index.php\/wp-json\/wp\/v2\/tags?post=372"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}