Signals and asynchronous activity completion use cases

[nitesh237]

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.

Signals Vs ActivityCompletionClient

I think you are confusing activities with operations that are executed by external entities like humans. If all you want is to execute three activities in a sequence then just invoke them synchronously one after another: activities.activity1(); activities.activity2(); activities.activity3(); The activity + reply signal pattern is needed when the actual work is done by an external system. For example, an existing REST service exposes an endpoint to initiate some action and then later delivers …

Signals vs Asynchronous Activity Completion

TLDR; I would use signals for 3, 4, and 6. While you could technically use the async activity completion for these, signals are a better fit. The reason is that initiating an operation can fail and should be retried and this requires timeouts and retry policy just for that operation. The reply from the user is usually can take much longer and has its own timeouts. Another reason for using signals for manual interactions is that such interactions frequently have multiple states. For example, a …

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: https://github.com/temporalio/samples-go/blob/main/updatabletimer/workflow.go#L34

• 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

[maxim]

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.

[nitesh237]

Thanks @maxim

[nitesh237]

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?

[tihomir]

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

[nitesh237]

Thanks for the quick response tihomir. That answers my question