Should we wrap long logic if-else in activity/local-activity?

func MyWorkflow(ctx, params) error {
      config, _ := workflow.ExecuteActivity(ctx, getConfigActivity)

      Logic: 100 lines of parsing config to find params for next activity

I provide the sudo-code here, my question is should I wrap the logic part in an activity? I have reasons to support or reject this idea.

  • Pro: so in the next replay of this workflow, this part will be static and not replayed, and if I changed the code here and has some inconsistency logic, it will not affect ongoing workflows with non-deterministic error;

  • Con: sending the message to temporal and asking the activity worker to handle this is too heavy for this if-else logic. Maybe local activity is a better choice?

Given the config parsing is pure CPU operation involves no IO, I would prefer local activity.

1 Like

How long does the parsing take? You typically do not want to use local activities for computations that exceed the default task timeout (10s).
Typically the advice is to to stick to normal activities unless your use case requires very high throughput and large activity fanouts of very short activities.

See here for more info.

I think in nanoseconds…I first put it in workflow with no activity at all as a common branch. But in case the logic gets different when we change the code wrapping in some light version of activity may be a good choice.

I think in nanoseconds

I believe using local activity should be ok for this case.

1 Like