What is the `WorkflowTask` status after `task` is replaced with a more recent version?

[jluethi]

Currently, updating a task leads to the status of that task being "lost" / set to None?.

In the larger work on how to handle statuses, especially with subsets: We should think about this design choice. I agree that a given version of a task did not run, so it's not wrong to say that task didn't run. It does look a bit confusing though, especially if earlier parts of a workflow are updated after later parts are run.

[tcompa]

In the current version, a WorkflowTask is strictly attached to a single Task, and we don't expose any way to modify this DB relationship. The operation of a version update is purely client-side, and its corresponding backend operations are:

1. Delete the WorkflowTask associated to the task with version 0.1.2.
2. Create a new WorkflowTask associated to the task with version 0.1.3.

Because the two objects are different (that is, they have different IDs), they don't have any common status.

TBD:

• Could we implement the replace-relationship feature in the backend (so that we would modify the relationship for an existing WorkflowTask)?
• Would this have any implication on history and provenance tracking?

[jluethi]

That makes sense.

This is nothing that we need to do a quick-fix for. But we should think about the desired outcome when we work more on status. Just giving the new task the old status is also potentially misleading, as that version of a task never ran.

I imagine we will have to do more in-depth thinking about statuses and whether they can report more than a single value per task for subsets. A status may need to report information that contains something like "Ran for wells A01, A02, A03. Not run for well B01, B02, B03". In that context, we should also think about what "ran in an older version of the task" means. And maybe even "Ran with different parameters"?

[tcompa]

See also #2055