`workflow_state`: treat pre-startcp tasks as succeeded

[MetRonnie]

Problem

When a workflow is warm started, there might be other workflows that are using a workflow_state xtrigger or polling task looking for a task at a cycle before the start cycle point.

Also, we think at the moment that a workflow_state testing for a pre-initial cycle point task will poll when it doesn't need to - it can fail immediately.

Proposed Solution

Make workflow_state check the workflow_params table of the target workflow and treat pre-startcp tasks as having succeeded, and treat pre-icp tasks as invalid.

[hjoliver]

Re "treat pre-icp tasks as invalid" - I don't think xtriggers can distinguish between "not satisfied" and "error" yet. I'm sure this is discussed somewhere. Of course deciding what is an error exactly is tricky - e.g. workflow_state needs to handle the upstream workflow not having been started yet - so even "no DB" is not an error.

[dwsutherland]

Should it be an opt-in feature of workflow_state? What if it's undesirable to have the downstream workflow kick off on work that wasn't done upstream? (even though I agree the opposite is usually the case so maybe an opt-out feature?)

[oliver-sanders]

This only applies to warm-starts (where we are starting the workflow at an arbitrary point in the graph). In this case the scheduler itself considers all prior tasks to have completed (per pre-initial logic).

This is done, e.g, to rewind the workflow back to a safe checkpoint to continue OR as the ultimate fallback in the event of unrecoverable scheduler failure (e.g, corrupt DB).

Downstream workflows will already have had the opportunity to trigger off of these tasks, but may have some dangling xtriggers which haven't started running yet for scheduling reasons. If ext-triggers (push) were used rather than xtriggers (pull), then all downstream workflows would already have been irreversibly notified.

If we were to warm-start the workflow at a later cycle rather than an earlier one (i.e, to fast-forward rather than re-wind the workflow), then this proposed behaviour would be dubious / debatable. Though I'm not aware of any use cases for fast-forwarding workflows via warm-starts. Skip-mode is currently the documented approach for fast-forwarding, though since 8.6, set is now a compelling option.

It's difficult to make this behaviour configurable as the configuration would need to be baked into the workflow_state poller tasks in the downstream workflows where it couldn't easily be amended to cater to specific circumstances. At which point it's easier just to control those tasks directly.