From 0cea0c8d9cde922c881c94e3076ae9892372be25 Mon Sep 17 00:00:00 2001 From: Brendan Irvine-Broque Date: Sat, 17 Oct 2026 08:25:35 -0700 Subject: [PATCH 1/2] [Workers] Announce Request.signal default on November 1 --- .../2026-10-17-request-signal-default.mdx | 51 +++++++++++++++++++ .../compatibility-flags/request-signal.md | 9 +++- .../docs/workers/runtime-apis/request.mdx | 2 +- 3 files changed, 59 insertions(+), 3 deletions(-) create mode 100644 src/content/changelog/workers/2026-10-17-request-signal-default.mdx diff --git a/src/content/changelog/workers/2026-10-17-request-signal-default.mdx b/src/content/changelog/workers/2026-10-17-request-signal-default.mdx new file mode 100644 index 00000000000..f7405d5fe43 --- /dev/null +++ b/src/content/changelog/workers/2026-10-17-request-signal-default.mdx @@ -0,0 +1,51 @@ +--- +title: Incoming Request.signal will be enabled by default on November 1 +description: Workers with compatibility dates on or after November 1, 2026 will receive abort events when clients disconnect, without an opt-in flag. +products: + - workers +date: 2026-10-17 +--- + +import { TypeScriptExample, WranglerConfig } from "~/components"; + +Starting November 1, 2026, Workers with a [compatibility date](/workers/configuration/compatibility-dates/) of `2026-11-01` or later will receive client disconnection events through `request.signal` by default. You will no longer need the `enable_request_signal` compatibility flag for these dates. + +We [introduced this opt-in behavior in May 2025](/changelog/post/2025-05-22-handle-request-cancellation/). It lets you log cancellations, clean up resources, or explicitly cancel work that accepts an `AbortSignal`. + +For example, this Worker logs a disconnection and passes the signal to an outgoing request so that it can be canceled too: + + + +```ts +export default { + async fetch(request): Promise { + request.signal.addEventListener( + "abort", + () => { + console.log("Client disconnected"); + }, + { once: true }, + ); + + return fetch("https://example.com/slow-response", { + signal: request.signal, + }); + }, +} satisfies ExportedHandler; +``` + + + +Your Worker keeps its current behavior until you update its compatibility date or explicitly opt in. To test before November 1, keep your existing date and add the flag to your [configuration](/workers/configuration/compatibility-flags/#setting-compatibility-flags): + + + +```toml +compatibility_flags = ["enable_request_signal"] +``` + + + +With a compatibility date of `2026-11-01` or later, you can opt out using `disable_request_signal`. This change does not enable `request_signal_passthrough`; the example passes the signal explicitly. + +For more information, refer to the [Request API](/workers/runtime-apis/request/#properties) and the [Request.signal compatibility flag](/workers/configuration/compatibility-flags/#enable-requestsignal-for-incoming-requests). diff --git a/src/content/compatibility-flags/request-signal.md b/src/content/compatibility-flags/request-signal.md index e60e43e6640..4c5ef32270d 100644 --- a/src/content/compatibility-flags/request-signal.md +++ b/src/content/compatibility-flags/request-signal.md @@ -1,8 +1,13 @@ --- name: "Enable `Request.signal` for incoming requests" -sort_date: "2025-05-22" +sort_date: "2026-11-01" +enable_date: "2026-11-01" enable_flag: "enable_request_signal" disable_flag: "disable_request_signal" --- -When you use the `enable_request_signal` compatibility flag, you can attach an event listener to [`Request`](/workers/runtime-apis/request/) objects, using the [`signal` property](https://developer.mozilla.org/en-US/docs/Web/API/Request/signal). This allows you to perform tasks when the request to your Worker is canceled by the client. \ No newline at end of file +For compatibility dates on or after November 1, 2026, incoming [`Request`](/workers/runtime-apis/request/) objects provide an [`AbortSignal`](https://developer.mozilla.org/en-US/docs/Web/API/Request/signal) that fires an `abort` event when the client disconnects. You can listen for this event to perform cleanup or write logs before the invocation ends. + +For earlier compatibility dates, add `enable_request_signal` to opt in. Add `disable_request_signal` to opt out, including with later compatibility dates. + +This flag does not change `request_signal_passthrough`. Pass `request.signal` explicitly to APIs that accept a signal, such as [`fetch()`](/workers/runtime-apis/fetch/), to cancel that work when the client disconnects. diff --git a/src/content/docs/workers/runtime-apis/request.mdx b/src/content/docs/workers/runtime-apis/request.mdx index ac7f6b9e012..80c8e9f8da5 100644 --- a/src/content/docs/workers/runtime-apis/request.mdx +++ b/src/content/docs/workers/runtime-apis/request.mdx @@ -265,7 +265,7 @@ All properties of an incoming `Request` object (the request you receive from the * The redirect mode to use: `follow`, `error`, or `manual`. The `fetch` method will automatically follow redirects if the redirect mode is set to `follow`. If set to `manual`, the `3xx` redirect response will be returned to the caller as-is. The default for a new `Request` object is `follow`. Note, however, that the incoming `Request` property of a `FetchEvent` will have redirect mode `manual`. * `signal` AbortSignal read-only - * The `AbortSignal` corresponding to this request. If you use the [`enable_request_signal`](/workers/configuration/compatibility-flags/#enable-requestsignal-for-incoming-requests) compatibility flag, you can attach an event listener to the signal. This allows you to perform cleanup tasks or write to logs before your Worker's invocation ends. + * The `AbortSignal` corresponding to this request. For compatibility dates on or after November 1, 2026, the signal fires an `abort` event when the client disconnects. For earlier dates, add the [`enable_request_signal`](/workers/configuration/compatibility-flags/#enable-requestsignal-for-incoming-requests) compatibility flag. You can listen for the event to perform cleanup tasks or write logs before your Worker's invocation ends. Use `disable_request_signal` to opt out. For example, if you run the Worker below, and then abort the request from the client, a log will be written: From f559a5fd68bdb98cfe8b347c05af3f7d65f5482f Mon Sep 17 00:00:00 2001 From: Brendan Irvine-Broque Date: Sat, 17 Oct 2026 09:06:40 -0700 Subject: [PATCH 2/2] [Workers] Add cf guidance to Request.signal changelog --- .../2026-10-17-request-signal-default.mdx | 29 ++++++++++++++----- 1 file changed, 21 insertions(+), 8 deletions(-) diff --git a/src/content/changelog/workers/2026-10-17-request-signal-default.mdx b/src/content/changelog/workers/2026-10-17-request-signal-default.mdx index f7405d5fe43..e38a696eab2 100644 --- a/src/content/changelog/workers/2026-10-17-request-signal-default.mdx +++ b/src/content/changelog/workers/2026-10-17-request-signal-default.mdx @@ -1,6 +1,6 @@ --- -title: Incoming Request.signal will be enabled by default on November 1 -description: Workers with compatibility dates on or after November 1, 2026 will receive abort events when clients disconnect, without an opt-in flag. +title: Request.signal will be enabled by default in Workers on November 1 +description: Workers with compatibility dates of November 1, 2026 or later will receive client disconnection events through request.signal by default. products: - workers date: 2026-10-17 @@ -8,11 +8,11 @@ date: 2026-10-17 import { TypeScriptExample, WranglerConfig } from "~/components"; -Starting November 1, 2026, Workers with a [compatibility date](/workers/configuration/compatibility-dates/) of `2026-11-01` or later will receive client disconnection events through `request.signal` by default. You will no longer need the `enable_request_signal` compatibility flag for these dates. +Starting November 1, 2026, Workers with a [compatibility date](/workers/configuration/compatibility-dates/) of `2026-11-01` or later will receive client disconnection events through `request.signal` by default. Use these events to stop unnecessary work when a client leaves. You will no longer need the `enable_request_signal` compatibility flag for these dates. -We [introduced this opt-in behavior in May 2025](/changelog/post/2025-05-22-handle-request-cancellation/). It lets you log cancellations, clean up resources, or explicitly cancel work that accepts an `AbortSignal`. +We [introduced this feature in May 2025](/changelog/post/2025-05-22-handle-request-cancellation/). You can log cancellations, clean up resources, or cancel operations that accept an `AbortSignal`. -For example, this Worker logs a disconnection and passes the signal to an outgoing request so that it can be canceled too: +For example, this Worker logs a client disconnection and cancels an outgoing request: @@ -36,9 +36,20 @@ export default { -Your Worker keeps its current behavior until you update its compatibility date or explicitly opt in. To test before November 1, keep your existing date and add the flag to your [configuration](/workers/configuration/compatibility-flags/#setting-compatibility-flags): +Existing Workers keep their current behavior until you change their compatibility date or flags. To try this feature before November 1, keep your current date and add `enable_request_signal` to your existing flags. With [`cf`](/cf/get-started/), set `worker.compatibilityFlags` in [`cloudflare.config.ts`](/cf/projects/cloudflare-config/). With Wrangler, set `compatibility_flags`: - + ```toml compatibility_flags = ["enable_request_signal"] @@ -46,6 +57,8 @@ compatibility_flags = ["enable_request_signal"] -With a compatibility date of `2026-11-01` or later, you can opt out using `disable_request_signal`. This change does not enable `request_signal_passthrough`; the example passes the signal explicitly. +With `cf`, run `cf dev` to test locally, then `cf deploy` to publish the change. For an existing Wrangler project, follow the [migration guide](/cf/wrangler/migrate/) before switching to `cf`. + +With a compatibility date of `2026-11-01` or later, use `disable_request_signal` instead of `enable_request_signal` in the same flags list to opt out. This change does not enable `request_signal_passthrough`. Pass the signal explicitly, as the example does. For more information, refer to the [Request API](/workers/runtime-apis/request/#properties) and the [Request.signal compatibility flag](/workers/configuration/compatibility-flags/#enable-requestsignal-for-incoming-requests).