Service bindings - do I need to use waitUntil() in this scenario?
Suppose I have a service binding from worker A to worker B. Worker A is triggered over HTTP, and hands off to worker B to do a task e.g. update a DB record or call a remote API.
Worker A does NOT need to know the result of worker B's task - it simply kicks it off. Worker A is then free to terminate. In this scenario, do I need to use
waitUntil()
in worker A or not? Struggling to understand when waitUntil()
is and is not required.
Thank you in advance.4 Replies
Thank you. So this means that, without
waitUntil
, worker B will shut down when worker A shuts down, is that right?
Thank you. (Cursor is giving me the opposite answer! AI, eh, what are you gonna do with it.)
If I use waitUntil()
, does worker B get its own fresh 30 seconds to run? Or must it operate within worker A's 30 seconds?To add to the response, waitUntil is used to handle whatever action you want to take asynchronously and not needed to fullfill the request
If you call worker B in ctx.waitUntil, I'd assume it has to terminate before the workers A terminate (but it's not explicitly said in the documentation)
Cloudflare Docs
Context (ctx) · Cloudflare Workers docs
The Context API in Cloudflare Workers, including waitUntil and passThroughOnException.
Thanks. Yeah I agree the docs are unclear on this. It says workers get 30 seconds (assuming a HTTP trigger) but it doesn't say whether workers invoked by service bindings must operate within that initial 30 seconds, or whether they get their own, fresh 30 seconds.