Implement new control API by danth · Pull Request #489 · eclipse-score/lifecycle

danth · 2026-08-18T13:05:57Z

This pull request adapts the launch manager (and tests) to use the new control API based on mw::com, and removes the old API.

Notable points

The State_Manager application type is now aliased to Reporting_and_Supervised.

Instead, mw::com access control must be used to prevent unwanted processes acting as state managers.
There is a workaround to make the process_fd_leak test pass, because there is no possibility to set O_CLOEXEC on mw::com's file descriptors when they are created.

I've opened an issue to fix this upstream: Set CLOEXEC on file descriptors communication#1064
External documentation needs to be updated before this is released.

Relevant issues

github-actions · 2026-08-18T13:07:58Z

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.7.0) and connecting to it...
INFO: Invocation ID: 888f0780-f607-43de-9fe8-7fb3cd200f21
Computing main repo mapping: 
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

Analyzing: target //:license-check (51 packages loaded, 10 targets configured)

Analyzing: target //:license-check (88 packages loaded, 10 targets configured)

Analyzing: target //:license-check (144 packages loaded, 737 targets configured)

Analyzing: target //:license-check (156 packages loaded, 4383 targets configured)

Analyzing: target //:license-check (158 packages loaded, 8562 targets configured)

Analyzing: target //:license-check (163 packages loaded, 9368 targets configured)

Analyzing: target //:license-check (169 packages loaded, 9541 targets configured)

Analyzing: target //:license-check (172 packages loaded, 11426 targets configured)

INFO: Analyzed target //:license-check (173 packages loaded, 11555 targets configured).
[12 / 16] Creating runfiles tree bazel-out/k8-opt-exec-ST-d57f47055a04/bin/external/score_tooling+/dash/tool/formatters/dash_format_converter.runfiles [for tool]; 0s local ... (2 actions, 1 running)
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 25.810s, Critical Path: 0.69s
INFO: 16 processes: 4 disk cache hit, 12 internal.
INFO: Build completed successfully, 16 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

WilliamRoebuck

A really great implementation, I have some small cleanup suggestions. I also rambled a bit about the API but I understand I may be a bit late on this so apologies if it's not relevant. As I'll be away from tomorrow, just comment and resolve if you disagree or I've misunderstood

WilliamRoebuck · 2026-09-07T12:22:06Z

-        // workaround to detect we're in fallback
+        // This verifies that a fallback process was actually started - the launch manager
+        // did not just send an event without taking the action.
        EXPECT_TRUE(std::filesystem::exists(fallback_file)) << "Fallback run target was not activated";


Can we just use get_active_run_target() here? Rather than repeating this step each test, we could have a single test to verify that a component configured to launch in fallback actually launched

I tried to make minimal changes from the old tests, but this can be cleaned up.

I think we should have a separate test which makes sure that the callbacks are telling the truth, then no further verification is needed in the other tests.

I think these improvements could be done in a separate pull request, so long as the tests are passing in their current state. :))

SimonKozik · 2026-09-09T10:44:12Z

        case fb::ApplicationType::Reporting_And_Supervised:
            return ApplicationType::ReportingAndSupervised;
-        case fb::ApplicationType::State_Manager:
-            return ApplicationType::StateManager;


I would recommend to translate fb::ApplicationType::State_Manager into ApplicationType::ReportingAndSupervised until we remove State_Manager from configuration schema.

Additionally we probably need to create work item to change configuration schema and to adapt translation script scripts/config_mapping/lifecycle_config.py

I have reverted the removal for now, and we just translate it to Reporting_and_Supervised. See also.

SimonKozik · 2026-09-09T12:54:51Z

+    const ActivateRunTargetRequest& request)
+{
+    SCORE_LANGUAGE_FUTURECPP_ASSERT_PRD_MESSAGE(
+        request.mode == ActivationMode::kForced, "Only ActivationMode::kForced is implemented");


If we don't have a work item already, we should create one.

The queue is the intended mode and forced flag should be used sparingly...

NicolasFussberger · 2026-09-10T14:00:22Z

+{
+    const auto instance_specifier_result =
+        InstanceSpecifier::Create(std::string{"LaunchManager/StateManager/Instance"});
+    SCORE_LANGUAGE_FUTURECPP_ASSERT_PRD_MESSAGE(


Could we give this error back to the user, e.g. with an init() method or a Create(..) call?
Then we can log an error in main and cleanly shutdown the process.

I suspect people run into this problem frequently when they first try to start LM without a mw::com config file that has this exact instance specifier defined. Then it would be more user friendly to have a nice error message instead of crashing on an assertion.

NicolasFussberger · 2026-09-10T14:02:02Z

+        instance_specifier_result.has_value(), instance_specifier_result.error().Message().data());
+
+    auto skeleton_result = LmControlSkeleton::Create(instance_specifier_result.value());
+    SCORE_LANGUAGE_FUTURECPP_ASSERT_PRD_MESSAGE(skeleton_result.has_value(), skeleton_result.error().Message().data());


Same here, I would also pass this back to main and log a nice error with more context.
E.g. Failed to setup mw::com communication for LmControl service...Error: <mw::com error>

NicolasFussberger · 2026-09-10T14:03:21Z

+namespace score::mw::lifecycle::internal
+{
+
+class ControlProvider


Maybe we can do it as a subsequent step in another PR to not block this one, but we should think how we can restructure the class so we can unit test it. I am not sure if we can provoke all the error cases without having some mocking mechanism in place.

I have been working on some unit tests locally... I think if we could somehow call the handle_ methods directly in the test, then it would be fairly simple to check their behaviour independently from mw::com. I'm not sure the best way to structure that though, as just marking them public would not be ideal.

NicolasFussberger · 2026-09-10T14:07:02Z

+Result<IdentifierHash> ProcessGroupManager::get_active_run_target() const
 {
-    return &process_interface_;
+    auto promise = concurrency::InterruptiblePromise<Result<IdentifierHash>>{};


If I remember correctly the Future/Promise from Score baselibs requires heap allocation. In that case we cannot really use this at runtime.

However, for this initial implementation I think it is still fine and we can exchange this later to not add too much complexity within this PR. Its a nice clean implementation using future promise.

This works around the `Graph` class not being thread safe.

This resolves several edge cases which the new version did not handle properly.

github-project-automation Bot added this to LCM - Lifecycle & Health FT Aug 18, 2026

danth requested a deployment to workflow-approval August 18, 2026 13:06 — with GitHub Actions Waiting

github-project-automation Bot moved this to Backlog in LCM - Lifecycle & Health FT Aug 18, 2026

danth force-pushed the control-api branch from 5f71352 to 4c6a6dd Compare August 18, 2026 13:39

danth requested a deployment to workflow-approval August 18, 2026 13:40 — with GitHub Actions Waiting

danth force-pushed the control-api branch from 4c6a6dd to 4cf8003 Compare August 18, 2026 13:42

danth requested a deployment to workflow-approval August 18, 2026 13:42 — with GitHub Actions Waiting

danth force-pushed the control-api branch from 4cf8003 to 6d66251 Compare August 19, 2026 08:17

danth requested a deployment to workflow-approval August 19, 2026 08:17 — with GitHub Actions Waiting

danth force-pushed the control-api branch from 6d66251 to bf414e3 Compare August 19, 2026 10:01

danth requested a deployment to workflow-approval August 19, 2026 10:01 — with GitHub Actions Waiting

danth force-pushed the control-api branch from bf414e3 to 9ab729f Compare August 19, 2026 13:32

danth requested a deployment to workflow-approval August 19, 2026 13:33 — with GitHub Actions Waiting

NicolasFussberger mentioned this pull request Aug 20, 2026

ControlClient: expose GetInitialMachineStateTransitionResult() and GetExecutionError() from ControlClientImpl to the public API #495

Closed

hskang-amelia mentioned this pull request Aug 21, 2026

Initial mw::com-based implementation of ilmcontrol interface #478

Merged

danth force-pushed the control-api branch from 9ab729f to 0ef7e8b Compare August 21, 2026 15:00

danth requested a deployment to workflow-approval August 21, 2026 15:00 — with GitHub Actions Waiting

NicolasFussberger reviewed Aug 24, 2026

View reviewed changes

Comment thread score/launch_manager/src/daemon/src/process_group_manager/process_group_manager.cpp Outdated

NicolasFussberger reviewed Aug 24, 2026

View reviewed changes

Comment thread score/launch_manager/src/daemon/src/process_group_manager/process_group_manager.cpp Outdated

danth force-pushed the control-api branch from 0ef7e8b to 8f07662 Compare August 24, 2026 07:55

danth requested a deployment to workflow-approval August 24, 2026 07:55 — with GitHub Actions Waiting