When does the fetch env object change?

[mild smelt]

For Workers using the ES Module format, they receive their environment variables and bindings through the fetch env object passed in as explained here:

https://developers.cloudflare.com/workers/runtime-apis/fetch-event/#syntax-module-worker

In the docs, it mentions the following regarding the env object:

The bindings assigned to the Worker. As long as the environment has not changed, the same object (equal by identity) is passed to all requests.

When would the env object change? Could this happen during the lifecycle of the script run?

I ask because we're migrating a large Worker codebase from the Service Worker format to the new Module format, but this codebase assumes the environment variables they rely on never change. So I'm trying to gauge whether it's going to be an issue having this assumption going to the Module format, and how much of an issue it will be.

[finite shard]

The env changes whenever you change it. Because of how the Module Syntax is set up, it can’t change during a Request lifetime, since it is inserted inline(while with Service Workers, it could theoretically have been changed at any time, since bindings are global). So, if anything, you should be less worried with Module Syntax

[mild smelt]

I'm not worried about the env object changing during a request, but between requests. This was something that didn't happen with Service Worker scripts, but seems possible with Module scripts based on the aforementioned piece of documentation. Like I mentioned, our codebase is not designed around the assumption that environment variables and bindings will ever change.

So my question remains: what are the triggers that cause the env object to change?

My prior understanding was that each request runs in an isolate (i.e. the fetch handler is never called more than once per script run) until I saw this part of the documentation (regarding the env variable). Is it no longer the case that each request fires in its own isolate?

[finite shard]

Ok, so a few things here:

1. Changes to the env object are triggered when you change it. Whether that be adding a new binding, adding a secret, etc. This is the same whether you are using Service Workers or Module Syntax.

2. As far as I know, multiple requests have always been able to share an isolate. The big thing is that, with the Module Syntax, it can change between requests without necessitating a full reboot of the isolate, since it can just pass in the new Environment for the next run of the fetch handler.

3. The fact that the env object can change between requests should not break any code, as long as it is written correctly. In general, the only thing we recommend persisting between requests, in the global scope or otherwise, are utilities(TextEncoder/Decoder, a Cache, etc.), or variables that you know you will not change. If you know you are rotating a secret frequently, do not store it anywhere it could be reused over multiple requests.

[mild smelt]

Thank you for clarifying. Unfortunately our code is not built around the assumption that environment variables could change. It seems that would require us to alter every method to pass in the env variable in the case one method several invokations deep needs an environment variable or binding. With the Service Worker format, this wasn't an issue.

I'm wondering what others have done about this if they're using the Module format?

[finite shard]

Again though, if a certain piece of your code relies on env.SOME_SECRET existing, then just never delete said secret, and it will always be there.

[rose birch]

Do changes to toml settings other than bindings and secrets trigger a change to the live deployment? For example, changing logpush from true to false -- would that affect the live deployment without running publish?