Existing documentation URL(s)
What changes are you suggesting?
The Workers documentation is incorrect and/or misleading in various places regarding maximum Duration (wall clock/time) of Worker invocations, e.g.
-
In various places the documentation describes waitUntil as having a 30 second time limit; either described as "delay cancellation for another 30 seconds" or "30 seconds after the response is sent or the client disconnects".
-
The Duration is described as "There is no hard limit on duration for HTTP-triggered Workers. As long as the client remains connected, the Worker can continue processing, making subrequests, and setting timeouts." without further qualification.
-
For Scheduled Handlers "ctx.waitUntil(promisePromise) : void - Use this method to notify the runtime to wait for asynchronous tasks"
However, testing (on Workers Free) reveals:
-
Fetch handlers (HTTP requests) terminate the Worker invocation 30 seconds after it has started. The response has to be returned within this time (so there is a hard limit), and waitUntil cannot extend beyond this limit (so not 30 seconds from the response being returned or client disconnection).
-
Scheduled handlers (and presumably Queue and Alarm handlers) wait for the returned Promise to resolve (for up to 15 minutes); it is not necessary to use waitUntil for asynchronous tasks (although they may be more convenient in some cases).
-
Scheduled handlers (and presumably Queue and Alarm handlers) wait for the returned Promise to resolve (for up to 15 minutes); it is not necessary to use waitUntil for asynchronous tasks. waitUntil remains useful for some concurrent task execution (especially from shared utility functions) and status reporting, but it is not necessary for extending the invocation duration.
Additional information
No response
Existing documentation URL(s)
What changes are you suggesting?
The Workers documentation is incorrect and/or misleading in various places regarding maximum Duration (wall clock/time) of Worker invocations, e.g.
In various places the documentation describes
waitUntilas having a 30 second time limit; either described as "delay cancellation for another 30 seconds" or "30 seconds after the response is sent or the client disconnects".The Duration is described as "There is no hard limit on duration for HTTP-triggered Workers. As long as the client remains connected, the Worker can continue processing, making subrequests, and setting timeouts." without further qualification.
For Scheduled Handlers "
ctx.waitUntil(promisePromise) : void- Use this method to notify the runtime to wait for asynchronous tasks"However, testing (on Workers Free) reveals:
Fetch handlers (HTTP requests) terminate the Worker invocation 30 seconds after it has started. The response has to be returned within this time (so there is a hard limit), and
waitUntilcannot extend beyond this limit (so not 30 seconds from the response being returned or client disconnection).Scheduled handlers (and presumably Queue and Alarm handlers) wait for the returned
Promiseto resolve (for up to 15 minutes); it is not necessary to usewaitUntilfor asynchronous tasks (although they may be more convenient in some cases).Scheduled handlers (and presumably Queue and Alarm handlers) wait for the returned
Promiseto resolve (for up to 15 minutes); it is not necessary to usewaitUntilfor asynchronous tasks.waitUntilremains useful for some concurrent task execution (especially from shared utility functions) and status reporting, but it is not necessary for extending the invocation duration.Additional information
No response