Does Temporal Typescript support workflow session

Community Support
,
1

I am using typescript and plan to have file download and decompression activities run on the same worker node to download a file and then decompress, my understanding is that temporal sessions are designed for scenarios like this, where certain activities need to execute on the same worker to maintain context or access shared resources efficiently.

Does Temporal Typescript SDK support workflow sessions too?

2

Typescript supports routing activities to specific hosts or processes using host/process specific task queues. Here is a Worker Specific Task Queues Sample.

The more user-friendly abstraction of the session is supported only on Go.

3

I follow the example you provided. What happens if we have multiple instances of the worker that needs to run an activity for the same worker i.e inter-dependent activities?
We will have require that we need to scale up the workers, we want to make sure that those inter-dependent activities run in the same node.

4

Sorry, I don’t understand the question. The example shows how to route multiple dependent activities to the same worker. Is it what you wanted?

5

Thank you for your reply, let me explain more.
In a scaled-up environment, Temporal’s default behavior distributes tasks to any available worker in the task queue.
In our case, inter-dependent activities requiring local state or shared resources (like a downloaded file activity then decompress the same file activity) need to run on the same worker instance. Could the above solution you gave lock the execution and guarantee the resource of multiple inter-activities within the same worker node in a scaled-up environment for our typescript case?

6

I see. The main session feature is the ability to limit the number of such sequences of activities that can run in parallel.

The session uses the following design and you can try to implement it yourself:

  1. Each process creates a separate worker with fixed parallelism (for example 1). Let’s call its task queue “process-lock”.
  2. Each process listens on a host specific task queue. For example, “host1”.
  3. To start the sequence of activities invoke “lock-process” activity at “process-lock” task queue.
  4. This activity starts executing at one of the free processes. While this activity is executing the process is considered locked by the caller.
  5. The lock activity is expected to run until it is canceled or an “unlock” activity is executed at the host specific task queue.
  6. When started the “lock” activity sends a “lock granted” signal to the workflow that invoked it. The signal argument contains the name of the host specific task queue to use.
  7. The workflow upon receiving the signal starts dispatching activities to the host specific task queue as long as needed.
  8. When the whole sequence of activities is completed the “unlock” activity is dispatched. This activity notifies the “lock-process” activity to complete.
  9. Once “lock-process” activity is completed the host is considered free and can pick up the next “lock-process” activity from another workflow.

Consider specifying ScheduleToStart timeout for the lock activity to limit how long a workflow is willing to wait for the lock.