Static Analysis Tool for Checking Workflow Registration

Community Support
1

Hi team,

I was wondering if there is a static analysis helper tool similar to workflowcheck that checks if a new workflow is registered or not with a temporal worker.

Thanks,
Mark

2

Can you clarify a bit here? Workflows are registered only with the worker, the server is unaware of which workflows are registered, it only knows if a worker is accepting work on a task queue.

3

Sorry, I misspoke. I meant registered with a temporal worker. my bad, I will edit the above message.

4

No prob! Can you clarify a bit on what you mean by “checks if a new workflow is registered or not” with regards to a static analysis tool? What specifically would such a tool check?

5

Sure! Basically checks to see if all the existing workflows we use, are registered with a worker through calling w.RegisterWorkflow. The reason why I am wondering because sometimes we add new workflows and use in the worker but forget to register it using w.RegisterWorkflow.

6

To confirm, are you saying that all calls to client.Client.ExecuteWorkflow that pass in a function reference need to check whether there is a worker somewhere registered with that same function reference?

The problem here is:

  • Many users do not have the client where they execute workflows from in the same module/code as the worker where they register them.
  • All we can know is that RegisterWorkflow is called somewhere at sometime with the function. We can’t know if that code is ever used. Maybe it’s code only used during a test.
  • Some users register workflows with multiple task queues and we cannot know at static check time whether which worker is which task queue and/or if that even matches the task queue for the client.

I think the best way here to solve your problem, if you do happen to have the registration and invocation code commonly located, is to abstract both sides yourself. The simplest way may be to maintain a list/map of workflows and you use that list for register and you confirm the workflow is in that list before executing it with the client. So essentially you have your higher level client that has more explicit workflow execution calls instead of the generic ExecuteWorkflow.

There are other ways to abstract too. But unfortunately it’s just not statically knowable with any reasonable guarantee whether a workflow was indeed registered with a worker (or if that worker was ever started, is only for test code, is a different task queue, etc). Technically we could have a tool that checks “any executed workflow or child workflow using a function reference also has some call anywhere in the codebase to register it” but that may have limited value for general use.