Affects Version/s: None
Fix Version/s: None
A long-standing hazard in our settings application architecture has been the case where two solutions have interdependent state. Most classically this emerged very early in the history of the project where we found that the value of the "cursors" registry settings under Windows are dependent on the desktop theme setting - writing to the latter will wipe out the former.
It now appears that this interdependence is responsible for
The best model for the problem is that, after passing through Couch's persistence, the order in which the preferences are retrieved are no longer stable, and we end up applying the cursor settings before the high contrast theme.
Note that this doesn't seem to be all of the explanation, since these settings appear in opposite orders in os_common.json5 and os_win7.json5 - we might need to study in more detail the pipeline in the matchmaker which ends up assigning solutions into "inferredConfiguration".
It seems the only sound way to head off this problem is to add some kind of "applicationPriority" annotation into the solutions registry - e.g. we would add, on "com.microsoft.windows.cursors", a member that says
priority: "after:com.microsoft.windows.highContrast" and then use the Infusion https://docs.fluidproject.org/infusion/development/Priorities.html system to sort the members of inferredConfiguration before sending them to settingsHandlers.
There seem to be two main places we might do the sort - i) we could do this inside the matchMaker before it returns its payload, and rely on all the transmission steps to preserve the sort order (conceivable now that the ES6 standard implies this must be done within a single VM, but risky given that external agents such as, e.g. Couch need not preserve them) https://github.com/GPII/universal/blob/master/gpii/node_modules/matchMakerFramework/src/MatchMakerUtilities.js#L382 -
or ii) we could do this within the LifecycleManager itself at sites like https://github.com/GPII/universal/blob/master/gpii/node_modules/lifecycleManager/src/LifecycleManager.js#L1233 , but this implies hitting at least 2 sites where we iterate over solutions in order to generate application tasks from them.