Check if an external workflow is running

Community Support
,
1

Say I am in workflowA
and i do:

const wfBHandle = getExternalWorkflowHandle(id);

is there some way where i can query the status of wfB? specifically i want to ensure wfB is running and then do something else.

The only way I’ve found right now that works is to basically wrap a try-catch around a noop signal to send to wfB.

2

You can call DescribeWorkflowExecution from an activity.

3

What is the something else that you want to do afterward? Beware of possible race conditions: even if you do check that wfB is running, there is no guarantee that it will still be running at the moment you do that other thing…

4

We have application level locking to ensure that this doesn’t happen. Specifically we want to wait for the workflow to be running so that we can signal it.

I cannot seem to find the API reference to call DescribeWorkflowExecution in the typescript SDK from a workflow. Can someone point me in the right way?

5

I cannot seem to find the API reference to call DescribeWorkflowExecution in the typescript SDK from a workflow. Can someone point me in the right way?

That would be something like:

await client.workflow.getHandle('workflow-id').describe();

We have application level locking to ensure that this doesn’t happen. Specifically we want to wait for the workflow to be running so that we can signal it.

Not sure I correctly understand what you mean here. Do you mean that:

  1. you need to make sure that wfB is actually running before you start doing something,
  2. that this something will eventually (ie. not immediately) send a signal to wfB,
  3. and that you have some external guarantee that if wfB was indeed running at step 1, then it will never complete execution before it receives the signal at step 2.

Is that really what you are saying?

6

Yes your description is correct. wfA will lock application level db entities in a way such that wfB’s activities cannot complete and ergo making wfB not complete until wfA finishes and releases the locks

7

Ok, and what should happen if, at step 1, it turns out that wfB is not running?

8

then wfA should not do anything until wfB is live. We just have a while loop with a sleep.

For some application context, wfA represents a manual intervention in our system whose objective is to affect the state of wfB which in this case is a core application workflow.

9

Ok, I see. Thanks for the explanation. That’s a bit unusual, but seems legit.

Now, given the use case you described, I wouldn’t have a loop in the workflow for that, as that means your workflow’s history would grow on each attempt. Instead, I would make a regular activity that asserts that that the target workflow is running, and fail otherwise (with a retryable error). You can then tune the retry policy on that activity to ensure that it gets periodically retried until the target workflow is finally found. Also, you should probably set some maximum number of attempt, or some maximum delay to wait for (ie. schedule-to-complete timeout), in case some issue prevent the target workflow from ever being launched.

It may additionally make sense to perform internal retry inside the activity itself, which means less work on your Temporal Cluster, but you’ll need to consider the impact this could have on your Worker’s activity execution slots and may implies using activity heartbeating.