Infinite Activity Start-To-Close Timeouts

Community Support
1

I have recently started using Temporal for a monitoring project. I am wondering about the following:

Each monitoring action should be indefinite. It may last infinitely long or at least until the user explicitly cancels it. I have provided heartbeat timeouts to the activity, but it gives the following error:

BadScheduleActivityAttributes: A valid StartToClose or ScheduleToCloseTimeout is not set on command.

Of course this can be avoided by giving it a timeout:
ctx = workflow.WithActivityOptions(ctx, workflow.ActivityOptions{StartToCloseTimeout: 10 * time.Second})

But in reality, it should never actually time out. The monitoring functionality should continue even if the endpoint actually does time out, and it should detect when it comes back up. That is the whole point of the activity.

The other option I can see is running the actual monitoring as a single activity with the provided timeouts as the user-defined constraints and using workflow.Sleep for the monitoring interval. Is this the standard approach to follow? Is there a limit of the number of activities that can be invoked by a workflow? It seems the Workflows can have essentially infinite timeout, but then there is no heartbeat per se.

2

I also received this recommendation from maxim:

In a rare case when the polling requires a periodic execution of a sequence of activities or activity arguments should change between retries a child workflow can be used. The trick is that a parent is not aware about a child calling continue as new. It only gets notified when a child completes or fails. So if a child executes the sequence of activities in a loop and calls continue as new periodically the parent is not affected until the child completes.

This is great to know because my activities should be executing as frequently as once every 10 seconds, and absolutely may change their parameters during the next invocation. Currently, my best bet is for within a workflow, to schedule an activity that reads the current parameters from my PSQL database and modify them if needed in the next activity scheduled.

e.g. A database record
MONITOR ID 112233:

  • Type: TCP
  • Host: 1.1.1.1
  • Port: 80
  • Timeout: 1 sec
  • Interval: 600 sec

What may happen is the user can update any of these values at any given time and I want the next invocation to contain the new settings. Maybe they change the port from 80 to 443 and the interval to 30 seconds instead of 600. Ideally, it wouldn’t wait the additional 570 seconds if I changed the value, but I believe I can use signals for that.

3

You can set the StartToClose timeout to some very large value, like ten years.

As far as the activity with changing polling parameters, I would perform both the periodic check of the DB and polling as part of the same activity.

1 Like