Could we add compile time checkers for workflow definition?

I read temporal docs and have found some principles to define workflow and activity correctly. For example, wrap business unit, say store some data in the DB, in the ExecuteActivity instead of directly put it in the workflow. My question here is, could we add some compiling checks on these bad use and detect them like they are just grammar errors?

My question here is, could we add some compiling checks on these bad use and detect them like they are just grammar errors?

Which SDK are you using? Not sure I understand the request, can you give sample that shows what you are asking for?

for the pseudo-code here

func workflow(ctx, params) {
        workflow.ExecuteActivity(funcX)
        direct call funcY()  // func Y should be wrapped in ExecuteActitiy, and is store some data in DB
}

This is a bad use case of Temporal definition right?
Could we develop some tools to find these bad use cases before something goes wrong in the runtime, for example, the tool can do something go vet/go race can do. (go sdk)

Thanks for explanation, I think your ideas is good. Would be interested to hear your opinion on the rules to enforce. Also take a look at this forum post on workflow determinism to get some further ideas.

direct call funcY()

Assume funcY is an activity function. Calling this in workflow code would typically manifest itself through non-deterministic errors or would trip the workflow deadlock detector. With Temporal both would imo not fail the workflow execution but block it, allowing users to fix the code and continue exec.

Yeah, I am reading. One side question is I think the link to Temporal Workers Tuning is broken. It returns internal error :slight_smile:

After some reading:

(1)
Yeah, I don’t think this causes non-deterministic because it does not generate commands and events when these code are not wrapped in workflow.ExecuteActivity(), and the sdk cannot compare these data for non-deterministic errors.

But I do agree deadlock and unexpected re-execution of funcY() happen all the time.

(2)
I have tried with the workflowcheck tool, but it fails to find out the bad pattern in my code. Could you help me on this?

Yes. https://github.com/temporalio/sdk-go/tree/master/contrib/tools/workflowcheck does just that. It’s about the best we can do with static analysis.

yeah, I have questions here.

  1. The workflowcheck does not work for me
    workflowcheck not working · Issue #814 · temporalio/sdk-go · GitHub

  2. do we have kotlin tool for static analysis?

  1. Looking at issue now
  2. No. We have considered JVM solutions for non-determinism checking, though of course it’s harder there because reflection is so much more prevalent and is a boundary which static analysis can rarely cross. We have also considered a JVM agent to catch such things during execution.

really appreciate your quick reply. I am in the Chinese timezone, and if my issue description is not enough for understanding, I can provide more information on slack/zoom or something else tomorrow. Thanks.

I think the link to Temporal Workers Tuning is broken. It returns internal error

Can you provide URL for the page where you found this? There were some bigger updates to docs yesterday and I am not able to find the page in your screenshot.
Direct url for worker tuning guide is here.

1 Like

I have tried with the workflowcheck tool, but it fails to find out the bad pattern in my code. Could you help me on this?

Don’t call your activity function directly, use workflow.ExecuteActivity instead.

yeah, I know. But we are trying to let others use it, and there will be someone use it badly, so compiling error will be good to prevent bad use cases.

Depending on the use case, one thing to maybe consider here is exposing a DSL to your end users (bonus if its backed by a json schema). This could shield your underlying implementation and possibly reduce potential end user errors (especially if they are non-technical). See examples for Go Java and TypeScript SDKs for reference.

1 Like