What is the current best practice or is there any roadmap for signalling workers from workflows or activities?
Our use case is to suspend polling in case e.g. the target system needs to undergo maintenance and any interaction is unwanted. This is usually done by users triggering something e.g. in a ticketing system… which would be neat to implement as a workflow by itself. The challenge is that the target system is accessed from Activities served by a dedicated worker (that can be e.g. placed in a specific network segment).
As per what I have read there is no method to access workers or their factories from any central point.
Based on available options I think a partial solution could be to have each worker registering a SignalWorkflow that would actually sleep forever but would implement a SignalMethod that would access the bootstrap class e.g. by having it as singleton. Then the challenge would be to have at least one SignalWorkflow running on each worker. It’s not really nice but in our case it could work because we have only one worker accessing the target system so we know that the SignalMethod will be run on that specific worker everytime.
It would definitely be better to have some way to signal e.g. all workers who have registered a specific Activity interface.
Workflows should not ever be tied to specific workers. You can have an activity listening on a worker-specific task queue. Then use that activity to act on other workers in the same process. This still would require some workflow to call such activity on every host. So a host when coming up would require registration through a signal to this notification workflow or getting identities of the workers from DescribeTaskQueue request and constructing queue name from identity for each worker.
I agree that the ability to pause a task queue through a service API would be very useful. Here is a relevant issue.
The service API able to act on queues is already a big step forward. But it does not solve the issue of distributing information to all workers.
Then a next step could be to let workers:
retrieve a dynamic config map scoped to a specific workflow or activity interface
being able updating such config maps
receive signals that the values have changed (subscribe pattern)
The issue to solve would be the expiration of such dynamic config map in case no worker has registered the given workflow or activity interface for some time since otherwise those config maps would remain in the system forever.