In certain cases, Sematic could get "stuck" waiting for something on one branch of a pipeline when more work could be done in other branches. This PR makes it so that Sematic will avoid entering a wait until changes are no longer being made to the pipeline state. Essentially the bug was that it can take a few iterations through the state-evolution loop before all the changes have taken effect that allow us to know it's OK to schedule a particular run. The fix was to look at whether the state-evolution loop resulted in anything in the pipeline changing state. And if it did, don't enter the wait.
Testing
Set up a pipeline that I knew would hit a condition that would wait prematurely before the fix. The sleep in the left branch of the image takes seconds, while the corresponding sleep in the right branch was configured to take hours.
Before, get stuck here until right sleep finishes:
After, progress as far as possible before waiting for the right, slow branch:
Closes #1120
In certain cases, Sematic could get "stuck" waiting for something on one branch of a pipeline when more work could be done in other branches. This PR makes it so that Sematic will avoid entering a wait until changes are no longer being made to the pipeline state. Essentially the bug was that it can take a few iterations through the state-evolution loop before all the changes have taken effect that allow us to know it's OK to schedule a particular run. The fix was to look at whether the state-evolution loop resulted in anything in the pipeline changing state. And if it did, don't enter the wait.
Testing
Set up a pipeline that I knew would hit a condition that would wait prematurely before the fix. The sleep in the left branch of the image takes seconds, while the corresponding sleep in the right branch was configured to take hours.
Before, get stuck here until right sleep finishes:
After, progress as far as possible before waiting for the right, slow branch: