Compatibility flags·续4

When you use the enable_request_signal compatibility flag, you can attach an event listener to Request objects, using the signal property ↗︎. This allows you to perform tasks when the request to your Worker is canceled by the client.

Cache API request cf overrides cache rules

When cache_api_request_cf_overrides_cache_rules is enabled, cache settings specified in the cf object of a request passed to the Cache API will override cache rules. This applies only to user-owned or grey-clouded sites.

This is the Cache API counterpart to the request_cf_overrides_cache_rules flag, which applies to the fetch() API.

Enable navigator.language

When the enable_navigator_language flag is set, the navigator.language property will be available in Workers. For now, the value of navigator.language will always be en.

When the disable_navigator_language flag is set, the navigator.language property will not be available.

Disallowing importable environment

When the disallow_importable_env flag is enabled, Workers will not allow importing the environment variables via the cloudflare:workers module and will not populate the environment variables in the global process.env object when Node.js compatibility is enabled.

There is no default enabled date for this flag.

Enable FinalizationRegistry and WeakRef

Enables the use of FinalizationRegistry ↗︎ and WeakRef ↗︎ built-ins.

• FinalizationRegistry allows you to register a cleanup callback that runs after an object has been garbage-collected.
• WeakRef creates a weak reference to an object, allowing it to be garbage-collected if no other strong references exist.

[!NOTE] [Behaviour] FinalizationRegistry cleanup callbacks may execute at any point during your request lifecycle, even after your invoked handler has completed (similar to ctx.waitUntil()). These callbacks do not have an associated async context. You cannot perform any I/O within them, including emitting events to a tail Worker. :::

[!CAUTION] These APIs are fundamentally non-deterministic. The timing and execution of garbage collection are unpredictable, and you should not rely on them for essential program logic. Additionally, cleanup callbacks registered with FinalizationRegistry may never be executed, including but not limited to cases where garbage collection is not triggered, or your Worker gets evicted. :::

Passthrough AbortSignal of incoming request to subrequests

Flag to enable	request_signal_passthrough
Flag to disable	no_request_signal_passthrough

When the request_signal_passthrough flag set, the AbortSignal of an incoming request will be passed through to subrequests when the request is forwarded to a subrequest using the fetch() API.

The the no_request_signal_passthrough flag is set, the AbortSignal of the incoming request will not be passed through.

Spec-compliant URLPattern implementation

Default as of	2025-05-01
Flag to enable	urlpattern_standard
Flag to disable	urlpattern_original

The original URLPattern implementation was not fully compliant with the WHATWG URLPattern Standard ↗︎, leading to a number of issues reported by users.

With urlpattern_standard enabled, Workers uses a spec-compliant URLPattern implementation. This is a breaking change from the original behavior, so it is gated behind a compatibility flag.

If you are using URLPattern and encounter unexpected behavior changes after updating your compatibility date, you can set urlpattern_original to revert to the previous implementation.

Navigation requests prefer asset serving

Default as of	2025-04-01
Flag to enable	assets_navigation_prefers_asset_serving
Flag to disable	assets_navigation_has_no_effect

For Workers with static assets and this compatibility flag enabled, navigation requests (requests which have a Sec-Fetch-Mode: navigate header) will prefer to be served by our asset-serving logic, even when an exact asset match cannot be found. This is particularly useful for applications which operate in either Single Page Application (SPA) mode or have custom 404 pages, as this now means the fallback pages of 200 /index.html and 404 /404.html will be served ahead of invoking a Worker script and will therefore avoid incurring a charge.

Without this flag, the runtime will continue to apply the old behavior of invoking a Worker script (if present) for any requests which do not exactly match a static asset.

When assets.run_worker_first = true is set, this compatibility flag has no effect. The assets.run_worker_first = true setting ensures the Worker script executes before any asset-serving logic.

Enable auto-populating process.env

Default as of	2025-04-01
Flag to enable	nodejs_compat_populate_process_env
Flag to disable	nodejs_compat_do_not_populate_process_env

When you enable the nodejs_compat_populate_process_env compatibility flag and the nodejs_compat flag is also enabled, process.env will be populated with values from any bindings with text or JSON values. This means that if you have added environment variables, secrets, or version metadata bindings, these values can be accessed on process.env.

const apiClient = ApiClient.new({ apiKey: process.env.API_KEY });
const LOG_LEVEL = process.env.LOG_LEVEL || "info";

This makes accessing these values easier and conforms to common Node.js patterns, which can reduce toil and help with compatibility for existing Node.js libraries.

If users do not wish for these values to be accessible via process.env, they can use the nodejs_compat_do_not_populate_process_env flag. In this case, process.env will still be available, but will not have values automatically added.

If the disallow_importable_env compatibility flag is set, the process.env will also not be populated.

Queue consumers don't wait for ctx.waitUntil() to resolve

Flag to enable	queue_consumer_no_wait_for_wait_until

By default, Queues Consumer Workers acknowledge messages only after promises passed to ctx.waitUntil() have resolved. This behavior can cause queue consumers which utilize ctx.waitUntil() to process messages slowly. The default behavior is documented in the Queues Consumer Configuration Guide.

This Consumer Worker is an example of a Worker which utilizes ctx.waitUntil(). Under the default behavior, this consumer Worker will only acknowledge a batch of messages after the sleep function has resolved.

```js export default { async fetch(request, env, ctx) { // omitted },

async queue(batch, env, ctx) { console.log(received batch of ${batch.messages.length} messages to queue ${batch.queue}); for (let i = 0; i < batch.messages.length; ++i) { console.log(message #${i}: ${JSON.stringify(batch.messages[i])}); } ctx.waitUntil(sleep(30 * 1000)); } };