Workers (Historic)·续2

New last week (forgot to post):

  • Added support for waitUntil() in Durable Objects. It is a method on the state object passed to the Durable Object class’s constructor.

2021-01-22

New in the past week:

  • Fixed a bug which caused scripts with WebAssembly modules to hang when using devtools in the preview service.

2021-01-14

Changes this week:

  • Implemented File and Blob APIs, which can be used when constructing FormData in outgoing requests. Unfortunately, FormData from incoming requests at this time will still use strings even when file metadata was present, in order to avoid breaking existing deployed Workers. We will find a way to fix that in the future.

2021-01-07

Changes this week:

  • No user-visible changes.

Changes in the prior release:

  • Fixed delivery of WebSocket “error” events.
  • Fixed a rare bug where a WritableStream could be garbage collected while it still had writes queued, causing those writes to be lost.

2020-12-10

Changes this week:

  • Major V8 update: 8.7.220.29 -> 8.8.278.8

2019-09-19

Changes this week:

  • Unannounced new feature. (Stay tuned.)
  • Enforced new limit on concurrent subrequests (see below).
  • Stability improvements.

Concurrent Subrequest Limit

As of this release, we impose a limit on the number of outgoing HTTP requests that a Worker can make simultaneously. For each incoming request, a Worker can make up to 6 concurrent outgoing fetch() requests.

If a Worker’s request handler attempts to call fetch() more than six times (on behalf of a single incoming request) without waiting for previous fetches to complete, then fetches after the sixth will be delayed until previous fetches have finished. A Worker is still allowed to make up to 50 total subrequests per incoming request, as before; the new limit is only on how many can execute simultaneously.

Automatic deadlock avoidance

Our implementation automatically detects if delaying a fetch would cause the Worker to deadlock, and prevents the deadlock by cancelling the least-recently-used request. For example, imagine a Worker that starts 10 requests and waits to receive all the responses without reading the response bodies. A fetch is not considered complete until the response body is fully-consumed (for example, by calling response.text() or response.json(), or by reading from response.body). Therefore, in this scenario, the first six requests will run and their response objects would be returned, but the remaining four requests would not start until the earlier responses are consumed. If the Worker fails to actually read the earlier response bodies and is still waiting for the last four requests, then the Workers Runtime will automatically cancel the first four requests so that the remaining ones can complete. If the Worker later goes back and tries to read the response bodies, exceptions will be thrown.

Most Workers are Not Affected

The vast majority of Workers make fewer than six outgoing requests per incoming request. Such Workers are totally unaffected by this change.

Of Workers that do make more than six outgoing requests concurrently for a single incoming request, the vast majority either read the response bodies immediately upon each response returning, or never read the response bodies at all. In either case, these Workers will still work as intended – although they may be a little slower due to outgoing requests after the sixth being delayed.

A very small number of deployed Workers (about 20 total) make more than 6 requests concurrently, wait for all responses to return, and then go back to read the response bodies later. For all known Workers that do this, we have temporarily grandfathered your zone into the old behavior, so that your Workers will continue to operate. However, we will be communicating with customers one-by-one to request that you update your code to proactively read request bodies, so that it works correctly under the new limit.

Why did we do this?

Cloudflare communicates with origin servers using HTTP/1.1, not HTTP/2. Under HTTP/1.1, each concurrent request requires a separate connection. So, Workers that make many requests concurrently could force the creation of an excessive number of connections to origin servers. In some cases, this caused resource exhaustion problems either at the origin server or within our own stack.

On investigating the use cases for such Workers, every case we looked at turned out to be a mistake or otherwise unnecessary. Often, developers were making requests and receiving responses, but they only cared about the response status and headers but not the body. So, they threw away the response objects without reading the body, essentially leaking connections. In some other cases, developers had simply accidentally written code that made excessive requests in a loop for no good reason at all. Both of these cases should now cause no problems under the new behavior.

We chose the limit of 6 concurrent connections based on the fact that Chrome enforces the same limit on web sites in the browser.

2020-12-04

Changes this week:

  • Durable Objects storage API now supports listing keys by prefix.
  • Improved error message when a single request performs more than 1000 KV operations to make clear that a per-request limit was reached, not a global rate limit.
  • wrangler dev previews should now honor non-default resource limits, for example, longer CPU limits for those in the Workers Unbound beta.
  • Fixed off-by-one line numbers in Worker exceptions.
  • Exceptions thrown in a Durable Object’s fetch() method are now tunneled to its caller.
  • Fixed a bug where a large Durable Object response body could cause the Durable Object to become unresponsive.

2020-11-13

Changes over the past week:

  • ReadableStream.cancel() and ReadableStream.getReader().cancel() now take an optional, instead of a mandatory, argument, to conform with the Streams spec.
  • Fixed an error that occurred when a WASM module declared that it wanted to grow larger than 128MB. Instead, the actual memory usage of the module is monitored and an error is thrown if it exceeds 128MB used.

2020-11-05

Changes this week:

  • Major V8 update: 8.6 -> 8.7
  • Limit the maximum number of Durable Objects keys that can be changed in a single transaction to 128.

2020-10-05

We had our usual weekly release last week, but:

  • No user-visible changes.

2020-09-24

Changes this week:

  • Internal changes to support upcoming features.

Also, a change from the 2020-09-08 release that it seems we forgot to post:

  • V8 major update: 8.5 -> 8.6

2020-08-03

Changes last week:

  • Fixed a regression which could cause HTMLRewriter.transform() to throw spurious “The parser has stopped.” errors.
  • Upgraded V8 from 8.4 to 8.5.

2020-07-09

Changes this week:

Changes last week (… forgot to post):

  • setTimeout/ setInterval can now take additional arguments which will be passed on to the callback, as required by the spec. (Few people use this feature today because it’s usually much easier to use lambda captures.)

Changes the week before last (… also… forgot to post… we really need to code up a bot for this):

  • The HTMLRewriter now supports the :nth-child , :first-child , :nth-of-type , and :first-of-type selectors.

2020-05-15

Changes this week:

  • Implemented API for yet-to-be-announced new feature.

2020-04-20

Looks like we forgot to post release notes for a couple weeks. Releases still are happening weekly as always, but the “post to the community” step is insufficiently automated… 4/2 release:

  • Fixed a source of long garbage collection paused in memory limit enforcement.

4/9 release:

  • No publicly-visible changes.

4/16 release:

  • In preview, we now log a warning when attempting to construct a Request or Response whose body is of type FormData but with the Content-Type header overridden. Such bodies would not be parseable by the receiver.

2020-03-26

New this week:

  • Certain “internal errors” that could be thrown when using the Cache API are now reported with human-friendly error messages. For example, caches.default.match("not a URL") now throws a TypeError.

2020-02-28

New from the past two weeks:

  • Fixed a bug in the preview service where the CPU time limiter was overly lenient for the first several requests handled by a newly-started worker. The same bug actually exists in production as well, but we are much more cautious about fixing it there, since doing so might break live sites. If you find your worker now exceeds CPU time limits in preview, then it is likely exceeding time limits in production as well, but only appearing to work because the limits are too lenient for the first few requests. Such Workers will eventually fail in production, too (and always have), so it is best to fix the problem in preview before deploying.
  • Major V8 update: 8.0 -> 8.1
  • Minor bug fixes.

2020-02-13

Changes over the last couple weeks:

  • Fixed a bug where if two differently-named scripts within the same account had identical content and were deployed to the same zone, they would be treated as the “same Worker”, meaning they would share the same isolate and global variables. This only applied between Workers on the same zone, so was not a security threat, but it caused confusion. Now, two differently-named Worker scripts will never be considered the same Worker even if they have identical content.
  • Performance and stability improvements.

2020-01-24

It has been a while since we posted release notes, partly due to the holidays. Here is what is new over the past month:

  • Performance and stability improvements.
  • A rare source of daemonDown errors when processing bursty traffic over HTTP/2 has been eliminated.
  • Updated V8 7.9 -> 8.0.

2019-12-12

New this week:

  • We now pass correct line and column numbers more often when reporting exceptions to the V8 inspector. There remain some cases where the reported line and column numbers will be wrong.
  • Fixed a significant source of daemonDown (1105) errors.

2019-12-06

Runtime release notes covering the past few weeks:

  • Increased total per-request Cache.put() limit to 5GiB.
  • Increased individual Cache.put() limits to the lesser of 5GiB or the zone’s normal cache limits.
  • Added a helpful error message explaining AES decryption failures.
  • Some overload errors were erroneously being reported as daemonDown (1105) errors. They have been changed to exceededCpu (1102) errors, which better describes their cause.
  • More “internal errors” were converted to useful user-facing errors.
  • Stability improvements and bug fixes.

Was this helpful?

YesNo

On this page

Workers (Historic)·续2 - 图1Docs

{"@context":"https://schema.org","@type":"TechArticle","@id":"https://developers.cloudflare.com/workers/platform/changelog/historical-changelog/#page","headline":"Workers (Historic)","description":"Review pre-2023 changes to Cloudflare Workers.","url":"https://developers.cloudflare.com/workers/platform/changelog/historical-changelog/","inLanguage":"en","image":"https://developers.cloudflare.com/workers/platform/changelog/historical-changelog/og.png?v=c057f83884b67a53","dateModified":"2026-04-23","publisher":{"@type":"Organization","name":"Cloudflare","description":"One platform for your apps, agents, and workforce. Build, secure, and scale without managing infrastructure","url":"https://www.cloudflare.com/","sameAs":["https://github.com/cloudflare","https://www.linkedin.com/company/cloudflare","https://x.com/cloudflare"],"logo":{"@type":"ImageObject","url":"https://developers.cloudflare.com/logo.svg"},"address":{"@type":"PostalAddress","streetAddress":"101 Townsend St","addressLocality":"San Francisco","addressRegion":"CA","postalCode":"94107","addressCountry":"US"},"contactPoint":[{"@type":"ContactPoint","contactType":"Customer Support","url":"https://support.cloudflare.com/","availableLanguage":["English"]},{"@type":"ContactPoint","contactType":"Sales","url":"https://www.cloudflare.com/contact/","availableLanguage":["English"]}]},"isPartOf":{"@type":"WebSite","@id":"https://developers.cloudflare.com/#website","name":"Cloudflare Docs","url":"https://developers.cloudflare.com/"}}

description: Deploy Workers before authentication, then claim the temporary account to keep its deployments and resources. title: Claim deployments (temporary accounts) image: https://developers.cloudflare.com/workers/platform/claim-deployments/og.png?v=a809402ad4ebb6d2

Skip to content

Documentation Index
Fetch the complete documentation index at: https://developers.cloudflare.com/workers/llms.txt
Use this file to discover all available pages before exploring further.