[Workers] Announce Request.signal default on November 1

src/content/changelog/workers/2026-10-17-request-signal-default.mdx

@@ -0,0 +1,64 @@
+---
+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
+---
+
+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. 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 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 client disconnection and cancels an outgoing request:
+
+<TypeScriptExample filename="src/index.ts">
+
+```ts
+export default {
+	async fetch(request): Promise<Response> {
+		request.signal.addEventListener(
+			"abort",
+			() => {
+				console.log("Client disconnected");
+			},
+			{ once: true },
+		);
+
+		return fetch("https://example.com/slow-response", {
+			signal: request.signal,
+		});
+	},
+} satisfies ExportedHandler;
+```
+
+</TypeScriptExample>
+
+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`:
+
+<WranglerConfig
+	cfConfig={`import { defineConfig } from "cf/config";
+
+export default defineConfig({
+	worker: {
+		name: "my-worker",
+		entrypoint: "./src/index.ts",
+		compatibilityDate: "2026-10-17",
+		compatibilityFlags: ["enable_request_signal"],
+	},
+});`}
+>
+
+```toml
+compatibility_flags = ["enable_request_signal"]
+```
+
+</WranglerConfig>
+
+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).

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.
+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.

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:
     <Render file="request-signal-example" product="workers" />