Uploaded image for project: 'GPII - Global Public Inclusive Infrastructure'
  1. GPII - Global Public Inclusive Infrastructure
  2. GPII-3693

Use of "reset to standard" corrupts PSPChannel's model



    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:


      This issue was discovered during user testing by Kavya, written up as "K1" in https://docs.google.com/document/d/1Ohi07CdjmH3WzBATBvJBZfql8blBdcSBTpE-IsHXmuA/edit#heading=h.5dfxhibyvazl - "Morphic 1.0.1 ATIA Demo Candidate Reported issues"

      Some limited developer testing suggests that this issue affects any use of the PSP which involves the "reset to standard" operation.

      This appears to be a regression introduced by the work in https://github.com/GPII/universal/pull/727 for GPII-3594 to simplify the LifecycleManager's session support - Javier Hernández has confirmed that reverting just this pull will resolve the issue.

      We've been discussing the issue in IRC starting here - http://irc-logs.fluidproject.org/%23fluid-work/%23fluid-work.2019-01-30.log

      I've made some limited experiments inspecting the system's model contents in the debugger and it does indeed seem that the PSPChannel from time to time receives a corrupt and empty model after the reset operation. I haven't traced the cause fully, but "by eye" from the original pull my expectation is that the problem is caused by having the special "RestoreSession" component always present attached to the LifecycleManager, whether a restore is in progress or not, and having an over-generous options distribution of the sessionBinder to all sessions attached to the FlowManager here - 


      I recommend that 

      i) To start with, we extend the existing PSPIntegrationTestDefs to include a test sequence which can demonstrate the failure in a self-contained way. This appears to involve a) activation of two settings in sequence, b) activating "reset to standard", c) activating any other setting, although it's possible this sequence could be simplified. This sequence could also be simplified by making use of "white-box testing" by inspecting the contents of both the session model and PSPChannel model at various moments, since it may take a longer sequence before the problem emerges in responses sent over the channel.

      ii) We focus the sessionBinder distribution to a more specific distribution such as 

       target: "{that lifecycleManager gpii.lifecycleManager.userSession}.options.gradeNames" 

      to ensure that only the genuine userSession becomes linked with the PSPChannel, and then verify that this resolves the problem

      iii) To further clarify the architecture, turn the restoreSession into a createOnEvent component which is only constructed when a restore action is in progress, and destroyed as soon as it concludes. This ensures that inactive components don't cause confusion by remaining in the system.

      Depending on how long we estimate this work might take, we might consider pulling Javier Hernández reversion of universal #727 into trunk, and moving this work into a refreshed pull request based on current master of an improved GPII-3594 fix incorporating the above.

      In any case the test sequence i) would be a very useful addition to the architecture since it reflects a failure in a real user usage pattern.




            cli@ocad.ca Cindy Qi Li
            amb26 Antranig Basman
            0 Vote for this issue
            3 Start watching this issue