You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Wait till the workflow moves on to e.g. cycle point 10, then trigger 1/foo with --flow=new.
All the foos will be spawned out to the current runahead limit before it gets updated to reflect the fact that the runahead base point has moved back to cycle point 1.
That's a bug under current intended behaviour.
However, in principle we should never reset the runahead limit backwards, at least not by default: if a new task or flow gets triggered earlier in the graph, why should we suddenly pause the main flow-front with a new, more restrictive runahead limit?
So: QUESTION
Should we default to never settting the runahead limit backwards
But provide a workflow setting, or a manual-trigger command option, to allow it for pragmatic reasons (workflow so big that performance is an issue for multiple concurrent flows: possibly it should be a workflow-specific thing).
The text was updated successfully, but these errors were encountered:
Wait till the workflow moves on to e.g. cycle point 10, then trigger
1/foo
with--flow=new
.All the
foo
s will be spawned out to the current runahead limit before it gets updated to reflect the fact that the runahead base point has moved back to cycle point 1.That's a bug under current intended behaviour.
However, in principle we should never reset the runahead limit backwards, at least not by default: if a new task or flow gets triggered earlier in the graph, why should we suddenly pause the main flow-front with a new, more restrictive runahead limit?
So: QUESTION
The text was updated successfully, but these errors were encountered: