What versions & operating system are you using?
current
Please provide a link to a minimal reproduction
n/a
Describe the Bug
workerd builds are imbued with the knowledge of the latest compatibility date they support, specified in supported-compatibility-date.txt.
If you try to tell workerd to run a worker that has a later compat date, it will error out, because it does not know how to run this worker correctly.
It turns out that wrangler, however, works around this check. If you ask for a newer date than your workerd supports, wrangler just automatically sets you back to the last supported date:
[wrangler:warn] The latest compatibility date supported by the installed Cloudflare Workers Runtime is "2025-12-23",
but you've requested "2026-02-02". Falling back to "2025-12-23"...
Features enabled by your requested compatibility date may not be available.
Upgrade to `wrangler@4.61.1` to remove this warning.
This defeats the purpose of the check in workerd which was very explicitly designed not to work this way.
Implicitly setting the compat date backwards means that wrangler is running the worker incorrectly.
Compat dates are not about "enabling features" as the warning text suggests. Compat dates are about controlling breaking API changes. It is extremely important that the worker run at exactly the date specified, otherwise it may break any time the interpretation of the date changes. For instance, if I set my compat date to 2026-02-02 but wrangler implicitly runs it with 2025-12-23 instead, then:
response.text() will not strip BOMs (changed 2026-01-13).- Stubs passed to RPC params will transfer ownership, instead of duplicating (changed 2026-01-20).
- Node-compat
require() will return the export namespace instead of the default export (changed 2026-01-22).
- Many other changes.
If I write code that uses any of this behavior, it may inadvertently rely on the old behavior. As soon as I deploy to production, the code will break. This is confusing.
wrangler must either run the worker at exactly the compat date specified, or error.
If the date is newer than what workerd supports, wrangler should recommend either updating wrangler.jsonc to match the supported date, or updating wrangler/workerd to a newer version.
Objection: "Then setting today's date as the compat date often won't work, which is frustrating to users."
We can solve this a different way: workerd releases could be designed to accept compat dates up to a week or two in the future. This is fine as long as newly-added flags will always set their default-on date to be beyond the currently supported date as of when the flag is merged. In fact, default-on dates are already generally set a few weeks in the future, as we need this time to make sure the flag reaches production before its default-on date. So changing workerd to support dates 1-2 weeks in advance is probably fine.
If workerd is more than a couple weeks old, then we really do need to tell the user to update if they want to use today's date.
Please provide any relevant error logs
No response
What versions & operating system are you using?
current
Please provide a link to a minimal reproduction
n/a
Describe the Bug
workerdbuilds are imbued with the knowledge of the latest compatibility date they support, specified in supported-compatibility-date.txt.If you try to tell
workerdto run a worker that has a later compat date, it will error out, because it does not know how to run this worker correctly.It turns out that
wrangler, however, works around this check. If you ask for a newer date than your workerd supports, wrangler just automatically sets you back to the last supported date:This defeats the purpose of the check in workerd which was very explicitly designed not to work this way.
Implicitly setting the compat date backwards means that wrangler is running the worker incorrectly.
Compat dates are not about "enabling features" as the warning text suggests. Compat dates are about controlling breaking API changes. It is extremely important that the worker run at exactly the date specified, otherwise it may break any time the interpretation of the date changes. For instance, if I set my compat date to 2026-02-02 but wrangler implicitly runs it with 2025-12-23 instead, then:
response.text()will not strip BOMs (changed 2026-01-13).require()will return the export namespace instead of the default export (changed 2026-01-22).If I write code that uses any of this behavior, it may inadvertently rely on the old behavior. As soon as I deploy to production, the code will break. This is confusing.
wrangler must either run the worker at exactly the compat date specified, or error.
If the date is newer than what workerd supports, wrangler should recommend either updating wrangler.jsonc to match the supported date, or updating wrangler/workerd to a newer version.
Objection: "Then setting today's date as the compat date often won't work, which is frustrating to users."
We can solve this a different way: workerd releases could be designed to accept compat dates up to a week or two in the future. This is fine as long as newly-added flags will always set their default-on date to be beyond the currently supported date as of when the flag is merged. In fact, default-on dates are already generally set a few weeks in the future, as we need this time to make sure the flag reaches production before its default-on date. So changing workerd to support dates 1-2 weeks in advance is probably fine.
If workerd is more than a couple weeks old, then we really do need to tell the user to update if they want to use today's date.
Please provide any relevant error logs
No response