Uploaded image for project: 'Fluid Infusion'
  1. Fluid Infusion
  2. FLUID-6406

Workflow scheduling algorithm allows an early block of instantiating components to run ahead of successors

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: IoC System
    • Labels:
      None

      Description

      This issue only affects the FLUID-6148 in-progress branch.
      The original version of the workflow scheduling algorithm, codenamed "ModelComponentQix" did not satisfy the original goals of always proceeding with the workflow of the least advanced component in the instantiating set.
      This was discovered when attempting to reform the GPII app's dialog instantiation workflow by means of an "intermediate dodge" of a lensed component defined purely to hoist the instantiation of the electron BrowserWindow until after model resolution, since its instantiation parameters depended on some model material.
      In outline we had:

      fluid.defaults("gpii.app.dialog", {
      ....
          dynamicComponents: {
              // Resolution for GPII-4147 to defer construction of the dialog until the component's model has been resolved
              dialogLoader: {
                  type: "fluid.modelComponent",
                  source: "{that}.model",
      ....
              },
          members: {
              dialog: "{that}.dialogLoader.dialog"
          }
      }
      

      In theory we should be able to guarantee that in the absence of an observer, evaluation of the shorthand member "dialog" (and any other similar late option observer) could not run ahead of the component. In practice, the algorithm, which we originally named "ModelComponentQix" would stubbornly progress the instantiation of an earlier workflow block even after a the group of "dialogLoader" lensed components had been contributed into the transaction record, by the original implementation

          fluid.applyWorkflowPhase = function (transRec, sequencer) {
              var shadows = transRec.outputShadows;
              // Bring any freshly created shadows to the same level as the most currently advanced
              if (shadows.length > transRec.lastWorkflowShadow && transRec.maximumWorkflowStage > 0) {
                  return fluid.enqueueWorkflowBlock(transRec, shadows, 0, transRec.maximumWorkflowStage,
                      transRec.lastWorkflowShadow, shadows.length, sequencer);
              } else if (transRec.maximumWorkflowStage < transRec.workflowStageBreak) {
                  // They must all be level - bring the level of all shadows to final level
                  return fluid.enqueueWorkflowBlock(transRec, shadows, transRec.maximumWorkflowStage, transRec.workflowStageBreak,
                      0, shadows.length, sequencer);
              }
          };
      

      The error is in the first branch, which always enqueues a early block up to the maximum workflow stage. Correctly, it should only enqueue a single strip at the next workflow stage, to ensure that they run ahead of freshly enqueued components to the smallest extent.

        Attachments

          Activity

            People

            Assignee:
            antranig Antranig Basman
            Reporter:
            antranig Antranig Basman
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated: