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…
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
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.