Workflow schedule behavior vs resetting workflow - how to keep max 1 workflow running at a time

Community Support
1

I have the following scenario:

  • there is a schedule defined for a workflow with a BUFFER_ONE policy (though no policy seems to achieve what I need)
  • sometimes, I need to reset the workflow (one that was triggered from a schedule)
  • it seems the schedule ignores that fact though, and even though I can see the workflow (the one I’ve reset) running in a schedule, it would still start a new workflow (when the scheduled time comes) while the restarted one is running, regardless of the policy, kind of like a reset workflow didn’t count when it comes to schedule policy

Is there any way to set this up properly? Or what would you advise is the easiest way to work around it?

What I’m trying to achieve is: I’d like only one schedule-defined workflow to run at a time, while I’d also like to be able to reset those workflows occasionally (I’m resetting from the UI).

PS Ideally, I’d like to work it the other way around as well, e.g. if I reset a workflow while a different workflow in a schedule is already running, I’d like the reset to fail or be a no-op. This is less of a concern though, I almost never reset any other workflow than the most recent one.

PS2 Am I crazy to want this and to wonder why it doesn’t work like this by default? I’m just wondering if I’m perhaps missing some core Temporal semantics or perhaps trying to use it in a non-intended way.

1 Like
2

You are not crazy, but I think reset is the piece that makes this feel surprising.

The way I would think about it is:

  • schedule overlap policy controls what the schedule does when it wants to start a new action
  • reset is a separate workflow-history operation, not a schedule action

So BUFFER_ONE can stop the schedule from stacking its own starts, but it does not really turn reset into part of the overlap accounting model the way you want.

If the real requirement is strictly max 1 active execution, the cleaner pattern is usually:

  1. give the scheduled workflow a stable workflow ID
  2. rely on Workflow ID conflict handling so a second start cannot create another open execution
  3. avoid UI reset as the normal restart mechanism
  4. instead signal or update the running workflow to reinitialize its internal state, or have it Continue-As-New when you need a clean run boundary

In other words, model restart as workflow logic, not as an external reset, if single-active-execution is the hard rule.

If you keep using UI reset, I would treat it as an operational tool, not something the schedule overlap policy will fully reason about.

If you want, I can sketch what this looks like with a fixed workflow ID plus Signal or Continue-As-New, since that is usually the least surprising setup for scheduled work that must stay singleton.

3

Thanks for answering! I would really appreciate that actually. I’m mostly interested in the “constant” workflow id for every scheduled workflow. That should be more than enough for my use case. I’m using Python SDK.