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

Stray reference to lifecycleManager breaks gpii-app tests with dynamic DR configuration



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


      Trying to integrate Astea's latest branches we run into a problem with very simple test configurations once trying to use the dynamic device reporter etc. together with the latest core. This can be reproduced by checking out the following branch of gpii-app https://github.com/danailbd/gpii-app/tree/fix/qssTests and running npm run test:noCoverage.

      The first error reported is

      02:04:11.574:  Initializing the ws server
      02:04:11.637:  ASSERTION FAILED: Failed to resolve reference {lifecycleManager} - could not match context with name lifecycleManager from component { typeName: "gpii.app" gradeNames: ["{that}.options.messageDistributorGrade","gpii.app.messageBundles","gpii.app","gpii.app.messageDistributor"] id: 9sa0ztwi-1106} at path serverEnvironment-9sa0ztwi-161,tests,configuration,server,cloudBasedConfig,server,flowManager,app component: {
          "typeName": "gpii.app",

      For some reason this fails to exit the tests immediately, which should be investigated separately, but then causes further failures in the IoC Testing Framework by corrupting the framework state.

      My best guess about what has happened is that some change in the configs has ended up moving some injected copy of the lifecycleManager out of line with the site in gpii.app which references it. It's unclear why this isn't affecting the production version of gpii.app which seems to run ok.

      Debugging hints - whilst it is possible to run node_modules\.bin\electron --inspect-brk tests.js it is not possible to put breakpoints in any Infusion framework code as a result of the back-versioned node/V8 engine inside the particular version of electron we are bound to. The best approach will probably be to print out the entire JSON of the fully merged config at the point it has got loaded within Kettle and study it to find where the stray reference has occurred. Sorry that Infusion's debugging supports are still not good enough to make tracking down this problem very easy.

      If you have any time, could you take a look at this, Cindy Qi Li? I will be back later in your afternoon to help out, cheers!




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