sporadic test failure in tServiceComponent.testUpdateConfigBeforeStartingBundleResolvesService

[jeffdiclemente]

To reproduce, run the following on Linux:

./usDeclarativeServicesTests --gtest_filter=tServiceComponent.testUpdateConfigBeforeStartingBundleResolvesService --gtest_repeat=-1 --gtest_break_on_failure

after a couple hundred iterations, it should fail with the following output:

[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from tServiceComponent
[ RUN      ] tServiceComponent.testUpdateConfigBeforeStartingBundleResolvesService
/mathworks/devel/sandbox/jdicleme/CppMicroServices_Org/development/compendium/DeclarativeServices/test/gtest/TestUpdateConfiguration.cpp:75: Failure
Expected equality of these values:
  compConfigs.at(0).state
    Which is: 1-byte object <00>
  scr::dto::ComponentState::ACTIVE
    Which is: 1-byte object <02>
Component state should be ACTIVE

[tcormackMW]

I don't think this is purely a race condition... If instead of the assertion, you waited on the state changing to ACTIVE, like below:

        while (compConfigs.at(0).state != scr::dto::ComponentState::ACTIVE)
        {
            compConfigs = GetComponentConfigs(testBundle, componentName, compDescDTO);
        }

The failing instance of the test case would never finish... i.e. this is not just 'we checked before some thread finished'

Additionally, when we first hit the while-loop, the componentConfig state is UNSATISFIED_REFERENCE and then it changes to a SATISFIED_REFERENCE but not an ACTIVE one.

There is no direct transition from UNSATISFIED_REFERENCE to ACTIVE, but there is from SATISFIED_REFERENCE to ACTIVE upon activation.

Additionally...

If you added the line GetInstance<test::CAInterface>(); as already existed 5 lines prior to this loop such that the loop looks like:

        while (compConfigs.at(0).state != scr::dto::ComponentState::ACTIVE)
        {
            instance = GetInstance<test::CAInterface>();
            compConfigs = GetComponentConfigs(testBundle, componentName, compDescDTO);
        }

the test no longer fails. When the loop is entered, the state of the compConfig[0] is UNSATISFIED_REFERENCE but after the two lines inside the while loop, it has changed to ACTIVE...

I'm not totally sure why this is happening... but I think it has to do with somehow DS not recording that an instance of the service was requested the first time through