About the implications of running child workflows in a different namespace than the parent

Community Support
1

Hi guys,

I have some questions about parent-child workflows in different namespaces. I know that a child workflow can be launched from a parent workflow in another namespace. The question is, what are the disadvantages of this scenario? I suspect that one of them could be related to replication and migration, as a namespace can be replicated to another cluster, which would break the parent-child “correlation.” However, I am not very familiar with replication.

On the other hand, since the SDK does not support handling multiple namespaces and task queues at the same time, it would also require extra resource usage to handle the workflows, one for each namespace. So, I believe that could be another inconvenience.

Are there any other disadvantages of having the parent and child workflows in another namespace?

Do you plan to allow handling multiple namespaces and task queues from a worker in the future? I don’t need an ETA :wink:

Lastly, I know it may be difficult to compare, but from the perspective of an SDK worker, would one that only implements workflows be lighter than one that only implements activities?

Best regards and thanks for the effort :wink:

2

We deprecated child workflows in different namespace feature. We don’t recommend using it. If you really need to start a workflow in a different namespace do it through an activity that starts it using workflow client.

In the future, we plan to support namespace-to-namespace communication through the Nexus project.

3

Thanks Maxim, I will change my approach. Regards.