Cloudflare Developers•2y ago

How does worker max time work precisely?

What (I think) I understand: - When using paid plan, you can make use of either Bundled or Unbound worker runtime. - In case of Unbound, the worker can last for a maximum of 30 seconds. - It can serve 6 multiple connections as the same time What I'm trying to figure out: - If my request takes 25 seconds to process, should I return a response immediately or after those 25 seconds? - How do I prevent a second reqeust from coming in after 5 seconds (at which point there isn't enough time to process the request during max runtime of the worker)? Most likely my mental model is somehow wrong, would love to learn!

3 Replies

WebberOP•2y ago

Does that mean every user request gets its own worker instance / v8 Isolate for every request? Ok that makes sense. However I would still like to know how a request that starts after 10 seconds would work. Does it mean the traffic to that worker instance gets rerouted to a new worker, and the request would be fine as long as it also completes in 25 seconds? Or put differently: Am I guaranteed that every request to any (unbound) worker instance will always have 30 seconds to be handled? I see. Very cool So in case of no rollout, but regular use, if I get a request every 5 seconds (and each request still takes 25 seconds to complete), the instance will be longer lived than 30 seconds. Is that also correct?

Unsmart•2y ago

Each instance can last many many hours if it keeps getting requests and it will guarantee every request gets at least 30 seconds to process before they do any evictions. Evictions really only happen for runtime updates and they will spin up a new instance with the new runtime while you have old requests using the old runtime if needed

WebberOP•2y ago

Awesome! One last follow-up question if you don't mind. In that case, why is env passed as part of the async fetch call? I realise that after an hour they might be a bit outdated, but is it also possible to load env manually (e.g. periodically)? Consider some code like:

app = expressLike(/* some elaborate application that needs `env` */)

export default {
  async fetch(req, env, ctx) {
     app.handle(req)
  }
}

app = expressLike(/* some elaborate application that needs `env` */)

export default {
  async fetch(req, env, ctx) {
     app.handle(req)
  }
}

Is there some good practice in handling env variables in cases like this? Ah right. I forgot. All the more reason to already have the env before fetch is called, I'd say - right? Meaning I should define my application routes (as well as any possible class instances) for every request - inside the fetch implementation? I see Thank you very much!

Gaming

Programming

How does worker max time work precisely?