Workflow submission version / configuration data not utilized in server-side workflow processing

[timcortesi]

Background:

Like App Instances, Workflow Instances can be tied to a specific workflow version and have their own workflow configuration. Once a workflow submission is made against a specific workflow instance, the workflow version associated with the instance at that time, along with a snapshot of the instance configuration, is copied over to the submission. Submissions were set up this way such that any workflow submission should continue to function even if the workflow instance is modified in some way (changing versions or configuration). In the database, each submission has a workflow_instance_configuration column where the configuration object is stored, as well as a workflow_version_id where the workflow version id is stored.

Findings:

While the workflow_submissions table is configured and properly populated as stated above, it does not appear that the server side processing of workflows themselves (Specifically the code within WorkflowSubmissionActionController and ResourceService) fully utilizes that data. In many cases, it is common to see things like $workflow_instance->configuration vs. $workflow_submission->workflow_instance_configuration which we might expect if things were behaving as expected.

New Branch with Code Changes:

In order to address these issues in the short term, a new branch of the workflow code has been created which attempts to address some of these issues. The new branch (https://github.com/EscherLabs/Graphene/tree/workflow-versions-bug-fix) was created from the following commit which was running on my.binghamton.edu: https://github.com/EscherLabs/Graphene/commit/3764b50048c497e6c25f5a4f26b46354125aea47 on 10/25/2023 when the issues outlined in this ticket were identified.

You can see a comprehensive list of changes here: https://github.com/EscherLabs/Graphene/compare/3764b50048c497e6c25f5a4f26b46354125aea47..6d968426c9db8715987a82a8276faadccaae5e36

This code is now running in prod on my.binghamton.edu as of 10/27/2023.

Explanation of Code Changes:

There are 3 files which have been changed:

WorkflowInstance.php The change in WorkflowInstance.php is to allow a workflow version id to be optionally sent to the findVersion function. Instead of this:

    public function findVersion() {
        $myWorkflowVersion = WorkflowVersion::where('id','=',$this->version['id'])->first();

We now see this:

      public function findVersion($workflow_version_id = null) {
        if (is_null($workflow_version_id)) {
            $myWorkflowVersion = WorkflowVersion::where('id','=',$this->version['id'])->first();
        } else {
            $myWorkflowVersion = WorkflowVersion::where('id','=',$workflow_version_id)->first();
            // Override Workflow Instance Version ID to correspond with the version found here
            // This is necessary so the getVersionAttribute function will return the correct workflow version
            $this->workflow_version_id = $myWorkflowVersion->id;
        }

This is necessary, because there are times when we want to manually specify the workflow version from the workflow_submission instead of relying on the workflow version associated with the instance. Examples of how this is used are shown further below.

WorkflowSubmissionActionController.php There are two types of changes in this file. The first is calling the modified findVersion function with the version id specified by the workflow submission.

Instead of this:

$myWorkflowInstance->findVersion();

we now see this:

$myWorkflowInstance->findVersion($workflow_submission->workflow_version_id);

Similarly, we also see updated references to the workflow submission configuration vs. the workflow instance configuration.

Instead of this:

$workflow_submission->state = $myWorkflowInstance->configuration->initial;

we now see this:

$workflow_submission->state = $workflow_submission->workflow_instance_configuration->initial;

ResourceService.php The changes made to the ResourceService function are very similar to the changes made to the WorkflowSubmissionActionController, except that additional checks have been made to confirm whether the workflow_submission is null. (There are a number of situations where the workflow submission is passed into the ResourceService as a null value, and so we cannot rely on that being set. In those cases, we fall back on the old logic.)

Instead of this:

$WorkflowInstance->findVersion();

We now see this:

        if (!is_null($workflow_submission)) {
            $WorkflowInstance->findVersion($workflow_submission->workflow_version_id);
        } else {
            $WorkflowInstance->findVersion();
        }

Instead of this:

if(isset($workflow_instance->configuration->resources)){

We now see this:

        if(!is_null($workflow_submission) && isset($workflow_submission->workflow_instance_configuration) && isset($workflow_submission->workflow_instance_configuration->resources)){
            $resources = $workflow_submission->workflow_instance_configuration->resources;
        } else if(isset($workflow_instance->configuration->resources)){

Takeaways

With the code changes as outlined above, we have managed to get my.binghamton.edu back online and working with these old workflow submissions. However, I would not necessarily recommend bringing these changes unaltered into the master branch without additional review or consideration. There may be a better way to handle these cases, and the code changes (while apparently functional) are not necessarily elegant (especially those within the ResourceService.php file).

With that said, some form of fixes needs to be made or we risk breaking compatibility with older submissions as was the case before the code changes were made.