Signals, Sleep and Queries


I want to ask a clarification for what happens if a workflow periodically goes to sleep, but I still want it to respond to signals and queries if any come along.

The question is if the workflow will indeed wake up to serve these? Going by this Caching API Requests With Long-Lived Workflows in Temporal, it would work for queries, but I was wondering how to handle signals in such a case. The background is that I might have thousands of workflows like this running and caching some data and potentially triggering something (email). I was thinking, that making them go to sleep would be a way to conserve resources.

Related to this would setting just a timer in the selector:

selector := workflow.NewSelector(ctx)
for i := 0; i < LifecycleMaxEvents || selector.HasPending(); i++ {
timer := workflow.NewTimer(tCtx, time.Second*100)
		selector.AddFuture(timer, func(f workflow.Future) {

Also suspend the workflow like sleep?

I would really appreciate it if somebody could clarify this. A trivial example would also be great.


I’m not sure why you need to sleep as waiting for a signal using Channel.Receive or Channel.ReceiveWithTimeout is already a blocking operation. Another option is to use workflow.Await or workflow.AwaitWithTimeout to wait for some condition to be satisfied.

Here is an example of using Await.

Thanks for the link. The example is quite useful.

My idea was to have multiple forever running workflows, which would respond to signals and periodically update an internal state themselves. I thought using sleep would be useful to suspend certain workflows, which are not being signalled or queried. I guess this is unnecessary.