Listener Exceptions No Longer Stop dispatchEvent() in Workers!

Hi everyone, it's Shii-chan!

Cloudflare Changelog developers.cloudflare.com

This update changes a default, so don't miss it!

What was announced?

The Cloudflare Changelog announced a new compatibility flag, spec_compliant_dispatch_exceptions. It aligns the Workers runtime's event dispatch behavior with the DOM specification.

The flag becomes the default for all Workers with a compatibility date of 2026-09-15 or later.

The story so far

When an event listener threw an exception during dispatchEvent(), the runtime propagated it immediately and skipped all remaining listeners for that event.

What changes

The spec says listener exceptions should be handled like this:

• They are reported through the global error event and the console
• Dispatch is not interrupted
• The remaining listeners still run

With the flag on, Workers follows that behavior. One failing listener no longer takes the others down with it.

Dive Deep

The change affects:

• The JS-visible dispatchEvent()
• AbortSignal abort dispatch
• Runtime-fired events on WebSocket, EventSource and MessagePort

It does not affect top-level event delivery for legacy Service Worker syntax entry points, such as addEventListener("fetch", ...).

There are two ways to control it:

• Opt in before the default date: add spec_compliant_dispatch_exceptions to your compatibility_flags
• Keep the old behavior after the default date: use no_spec_compliant_dispatch_exceptions

spec_compliant_dispatch_exceptions
no_spec_compliant_dispatch_exceptions

Wrap-up

• A throwing listener no longer stops the remaining listeners
• Exceptions are reported via the error event and the console
• It is the default for compatibility dates of 2026-09-15 or later
• You can opt in early or keep the old behavior with flags

If your code relies on how exceptions in listeners behave, it's worth checking before the date arrives!