If you need to manipulate state - you should use Deno KV or some other persistent database. V8 isolates are created on-demand to handle Deno.cron and Deno.serve requests, potentially in different regions. You should not make assumptions that the same isolate will be used to handle all requests.
I love Deno, and it is because it usually avoids these kind of footgun situations. It is hard to grok that you can access those variables in the shared scope, but if you manipulate them, they are actually in completely different isolates. I understand architecturally why it is that way right now though.
I just wish there it was more obvious that you are really inheriting a fresh state somehow. Maybe only `const` should be allowed at the top-level? That still wouldn't handle objects really, but it'd be better than nothing.
Is this really that surprising of a behavior, though? PHP apps threw away state after each request, and in the Node.js world data doesn't persist across server restarts or across instances of the app.
The only way I could see someone being confused about this is if they thought Deno Deploy was just a single VM running a single instance their code.
It is surprising behavior, because if the code can be accessed inside the scope, it is safe to assume that any modification to it will change the state, since it is still inside closure. If they throw `s++` with accessing undefined variable error, it will be much better. It'll be better if they can catch it during compile / validating / linting level.
And yes, PHP's behavior is surprising too. Unless we're doing scratch PHP without any classes or frameworks, any temporary variables become non-intuitive.
Kind the point of Deno Deploy is that you never have to think about a unit like a VM or container.
The runtime shouldn’t allow you to mutate variables in a parent scope. It probably shouldn’t allow any shared context at all. Because it isn’t actually doing that.
Everything should be passed into the cron function as an argument. It seems like this should be more like the interaction with web workers where those clearly execute in their own context.
> The runtime shouldn’t allow you to mutate variables in a parent scope. It probably shouldn’t allow any shared context at all. Because it isn’t actually doing that.
What you're proposing alters the semantics of JavaScript-the-language, which is outside the scope of the Deno project. Pretty much everyone is already in the habit of avoiding variables in the global scope. Why should they go to the trouble of redefining the semantics of JavaScript for something that is already widely understood?
`Deno.cron` isn't JavaScript-the-language. It is part of a runtime. They could implement this in a different way. Just like how Web Workers still just use JavaScrip-the-language, but within a different execution context than `<script>`.
Yes, we're anticipating more spiky workloads because of this. Deno Deploy is already designed to handle spikes, but we also have a few additional mitigations in place for Cron. For example, we will limit concurrent dispatches for the same project/user/organization, which may slightly delay the execution of specific cron tasks.
Or add a default randomness factor that makes it run within a certain time (like 60s or 5m) of the target, perhaps with an additional charge to run at the exact time if people have that requirement.
