Signals and asynchronous activity completion use cases

Hi Team,

Apologies for raising this topic again but the guidelines as to where to use Signal vs Async Activity completion were not very clear.

I have tried reading the following thread comments.

IIUC I don’t see any significant use-case where we would want to use asynchronous activity completion. Please correct me if I am missing something here.

  • Use case 1: Async request invocation and processing it in a separate process/thread pool
    We can model request initiation as an activity in itself to handle retries and failure as mentioned in the above thread and wait for the activity completion signal in the workflow. Further, to handle timeouts on the wait duration, we can use timers as showcased in the example: samples-go/workflow.go at main · temporalio/samples-go · GitHub

  • Use case 2: Blocking workflows and unblocking based on human actions/approvals
    This case can also be handled by blocking workflows using signals channels until the user approves.

  • Use case 3: Receiving multiple activity updates from external system
    This use case can only be solved using a signal as async activity completion doesn’t support multiple updates.

  • Any missing use-case ?

As we can see there is nothing that we can’t solve using a signal that is solvable by using async activity completion. In fact, we get more advantages if we use signals in most places. It will help if we can provide some better guidelines around the same so that we can some clear distinctions on the use cases.

~Nitesh

Yes, you can always replace an async activity completion using an activity and a signal. But I believe “Use Case 1” is better to implement as an async activity completion. The benefits of activity in this case are:

  • Activity retries
  • Activity heartbeats
  • Activity timeouts

All of the above without growing workflow history.

Thanks @maxim

quick follow up on the heartbeat part. What can we store with in heartbeat? Can we store any serializable object? Have seen in a few examples we store an index to store the progress. Is it okay to store an object instead, for storing the progress of a long-running activity?

Yes, heartbeat details can be any object type that can be serialized/deserialized by either sdk default or your custom data converters.

Thanks for the quick response tihomir. That answers my question