Affects Version/s: None
Fix Version/s: None
Component/s: IoC System
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:
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
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.