WFCORE-3624 is a specific example of a more general problem – services that may be recorded as dependencies of services installed by management ops are not tracked by the ContainerStateMonitor. This makes it possible to get problems like WFCORE-3624.

In practice WFCORE-3624 is fairly unique, as the problem service was ON_DEMAND. Also, most services installed by HostControllerService and ApplicationServerService are themselves dependencies of DomainModelControllerService and ServerService (which provide the ModelController) so if they are not started no management ops can proceed. But the code would be more robust if the way these were installed involved logic that led to them being tracked by the StabilityMonitor used by ContainerStateMonitor. Doing this would help ensure that future services like this don't fall into a crack the way ExternalManagementRequestExecutor did.

Note – I don't think DomainModelControllerService and ServerService themselves should be monitored. Not HostControllerService and ApplicationServerService either.

Here's some analysis I did when trying to figure out WFCORE-3624:

HostControllerService
---------------------
ProcessControllerConnectionService – DMCS depends
HostControllerExecutorService – DMCS depends
HostPathManagerService - DMCS depends
HostControllerScheduledExecutorService – no dep
Value<ProductConfig> – no dep
ExternalManagementRequestExecutor – no dep

ApplicationServerService
------------------------
ContentRepositoryImpl or RemoteFileRepositoryService – SS depends
ContentCleanerService – no dep
ServerDeploymentRepositoryImpl – SS depends
ServiceModuleLoader – SS depends
ExternalModuleService – SS depends
ServerPathManagerService – SS depends
ServerEnvironmentService – no dep
Value<ProductConfig> – no dep
ServerExecutorService – SS dep if executor is configured
ServerScheduledExecutorService – no dep
ExternalManagementRequestExecutor – no dep