Launch Manager loads the new configuration file by paulquiring · Pull Request #248 · eclipse-score/lifecycle

paulquiring · 2026-06-15T14:18:09Z

Map user-facing json config to the new flatbuffer config
Load new launch manager config
Introduce adapters to make the rest of the code work with the new configuration content
Remove the legacy configuration files

Closes: #209

github-actions · 2026-06-15T14:19:10Z

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.4.2) and connecting to it...
INFO: Invocation ID: 87349e67-6baf-4dc4-8451-12ef92285d38
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: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

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

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

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

Analyzing: target //:license-check (138 packages loaded, 2721 targets configured)

Analyzing: target //:license-check (150 packages loaded, 5404 targets configured)

Analyzing: target //:license-check (155 packages loaded, 5453 targets configured)

Analyzing: target //:license-check (155 packages loaded, 5453 targets configured)

Analyzing: target //:license-check (155 packages loaded, 5453 targets configured)

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

Analyzing: target //:license-check (160 packages loaded, 9062 targets configured)

Analyzing: target //:license-check (162 packages loaded, 10142 targets configured)

Analyzing: target //:license-check (162 packages loaded, 10142 targets configured)

Analyzing: target //:license-check (162 packages loaded, 10142 targets configured)

Analyzing: target //:license-check (162 packages loaded, 10142 targets configured)

Analyzing: target //:license-check (162 packages loaded, 10142 targets configured)

INFO: Analyzed target //:license-check (163 packages loaded, 10268 targets configured).
[13 / 16] JavaToolchainCompileClasses external/rules_java+/toolchains/platformclasspath_classes; 0s disk-cache, processwrapper-sandbox
[14 / 16] JavaToolchainCompileBootClasspath external/rules_java+/toolchains/platformclasspath.jar; 0s disk-cache, processwrapper-sandbox
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: 31.286s, Critical Path: 2.50s
INFO: 16 processes: 12 internal, 3 processwrapper-sandbox, 1 worker.
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>]

S-MOHAMD · 2026-06-17T16:47:59Z

Please lnk corresponding issue/bug.
see: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue

github-actions · 2026-06-18T08:33:36Z

The created documentation from the pull request is available at: docu-html

NicolasFussberger · 2026-06-23T06:41:28Z

-                                << std::string_view{f_exception_r.what()};
+            const auto* comp = supervised_components_[idx];
+            const std::string checkpointCfgName = comp->name + "_checkpoint";
+            const uint32_t checkpointId = 1U;


Not sure if this is worth it, but the checkpointId has to match this

lifecycle/score/launch_manager/src/alive/src/alive.cpp

Line 21 in 58d6d1b

static constexpr std::uint32_t kDefaultCheckpointId{1U};

I wonder if we should make this a static constant in score/launch_manager/src/daemon/src/alive_monitor/details/factory/StaticConfig.hpp which is then used in both places.

The background is, when this code was still supporting Deadline and Logical supervisions, then different kinds of checkpoints were required.
But now only Alive supervision support is left, which only needs sending "Alive notificiations" - for which he just use checkpointId 1.

We would need to reorganize the code a bit
Looking at:

score/launch_manager/src/daemon/src/alive_monitor/details/factory/StaticConfig.hpp
score/launch_manager/src/alive/src/alive.cpp

we might want to move StaticConfig.hpp into score/launch_manager/src/common or a similar location. We might want to create a ticket out if this comment to work in it later?

Ticket for removal of this id already exists #251

NicolasFussberger · 2026-06-23T06:53:06Z

    void logConfiguration() noexcept(true);

    /// @brief Configured watchdog devices
-    /// By default, no watchdog device is configured


Maybe we should bring back some of this doxygen, thats seems rather useful

paulquiring · 2026-06-22T12:08:48Z

+    // strdup() returns nullptr on OOM. On this embedded target, OOM during daemon
+    // startup is unrecoverable — the OS will terminate the process.
+    size_t arg_index = 0U;
+    startup.argv_[arg_index++] = strdup(startup.executable_path_.c_str());


We could use comp.deployment_config.executable_path.c_str(), but this would create a mixed ownership between the configuration object in main and the adapter. The Adapter copies the configuration so that it owns it. Yes this costs a bit of resources but is the simplest and clearest way currently to bridge the old to new configuration.

NicolasFussberger · 2026-06-23T06:58:16Z

+        const auto& wd = *wd_opt;
+        watchdog::DeviceConfig wdConfig{};
+        wdConfig.fileName = wd.device_file_path;
+        assert(wd.max_timeout_ms <= std::numeric_limits<std::uint16_t>::max());


Should we make this a validation in score/launch_manager/src/daemon/src/configuration/details/flatbuffer_type_converters.cpp ?

NicolasFussberger · 2026-06-23T07:11:39Z

+        }
+        dep.target_process_id_ = IdentifierHash{dep_name};
+        os_process.dependencies_.push_back(dep);
+    }


I think here is a bug. We need to lookup the ReadyCondition process_state for the referenced component.

I think it would be good to extend the UTs with these different state combinations to catch this

NicolasFussberger · 2026-06-23T07:19:38Z

+        for (const auto& comp_name : fallback.depends_on) {
+            auto it = component_to_process_index.find(comp_name);
+            if (it != component_to_process_index.end()) {
+                fallback_state.process_indexes_.push_back(it->second);


I think here we also need to resolve the dependencies recursively.

E.g. fallback_run_target depends_on [CompA]
and CompA depends_on [CompB] then

fallback_run_target = [CompA, CompB]

I think it would be good to extend the UT with this case

NicolasFussberger · 2026-06-24T12:50:18Z

-    true)
-{
-    return score::lcm::IdentifierHash{f_processPath_r}.data();
+std::optional<common::ProcessId> FlatCfgFactory::getProcessId(


std::optional no longer required, hashing cannot fail

NicolasFussberger · 2026-06-24T13:20:02Z

+    pg.off_state_ = IdentifierHash{"MainPG/Off"};
+
+    IdentifierHash recovery_state{"Recovery"};
+    for (const auto& rt : config.runTargets()) {


Could be changed to just
IdentifierHash recovery_state = IdentifierHash{std::string("MainPG/") + "fallback_run_target"};

without the for loop

NicolasFussberger · 2026-06-24T13:22:18Z

+        component_by_name[comp.name] = &comp;
+    }
+
+    std::map<std::string, uint32_t> component_to_process_index;


do we need a separate map just for the index or can we get the index from component_by_name?

NicolasFussberger · 2026-06-24T13:29:07Z

+    size_t arg_index = 0U;
+    startup.argv_[arg_index++] = strdup(startup.executable_path_.c_str());
+    size_t max_args = std::min(props.process_arguments.size(),
+                               static_cast<size_t>(score::lcm::internal::kMaxArg));


should we assert that we have enough space for all configured process_arguments and env variables?
kMaxArg with 20 is rather small, can we bump this to 100?

NicolasFussberger · 2026-06-24T13:31:32Z

+    bool is_sup = (props.application_profile.application_type == ApplicationType::ReportingAndSupervised ||
+                    props.application_profile.application_type == ApplicationType::StateManager);
+    if (is_sup && env_index < static_cast<size_t>(score::lcm::internal::kMaxEnv)) {
+        std::string iface_path = "LCM_ALIVE_INTERFACE_PATH=" + score::lcm::internal::aliveInterfacePath(comp.name);


we could also add a constant for the env name

NicolasFussberger · 2026-06-24T13:38:17Z

+                    ? score::lcm::ProcessState::kRunning
+                    : score::lcm::ProcessState::kTerminated;
+            }
+        }


here is a possible error case. In case the configured dependency does not actually exist

NicolasFussberger · 2026-06-24T13:39:30Z

+        pgm.number_of_restart_attempts = deploy.ready_recovery_action->number_of_attempts;
+    }
+
+    for (const auto& dep_name : props.depends_on) {


depends_on might also contain a run_target and not only a component.
Special Case: This may be also the fallback_run_target

NicolasFussberger · 2026-06-24T13:41:23Z

+            }
+        }
+        auto rt_it = run_target_by_name.find(dep_name);
+        if (rt_it != run_target_by_name.end()) {


I think depends_on might also refer to fallback_run_target which is currently not in the run_target_by_name map

NicolasFussberger · 2026-06-24T13:46:56Z

+        run_target_by_name[rt.name] = &rt;
+    }
+
+    std::map<std::string, const ComponentConfig*> component_by_name;


component_by_name exists twice in this class

NicolasFussberger · 2026-06-24T13:52:52Z

+                          std::set<std::string>& visited) {
+        if (!visited.insert(dep_name).second) return;
+        auto comp_it = component_to_process_index.find(dep_name);
+        if (comp_it != component_to_process_index.end()) {


There might be some possible error cases when component/runTarget names are not found because they have not been configured

Maybe we keep the current validation in the python script and just put asserts in the code for these error cases

NicolasFussberger · 2026-06-24T13:53:14Z

+        component_by_name[comp.name] = &comp;
+    }
+
+    std::function<void(const std::string&, std::vector<uint32_t>&, std::set<std::string>&)> resolve_depends;


Maybe it could make sense to have a dedicated Visitor class for this

NicolasFussberger · 2026-06-24T14:04:58Z

+}
+
+void ConfigurationAdapter::resolveDependencyIndexes(std::vector<OsProcess>& processes) {
+    for (auto& proc : processes) {


Is this needed?

NicolasFussberger · 2026-06-24T14:08:36Z

+        component_by_name[comp.name] = &comp;
+    }
+
+    std::map<std::string, uint32_t> component_to_process_index;


should we build these maps once during initialize and store them as private member?

NicolasFussberger · 2026-06-24T14:15:40Z

+    if (pg) {
+        if (index < pg->processes_.size()) {
+            return pg;
+        }


does not make sense to validate the index here

NicolasFussberger · 2026-06-24T14:16:32Z

+
+    static const uint32_t kDefaultProcessExecutionError;
+    static uint32_t kDefaultProcessorAffinityMask();
+    static const int32_t kDefaultSchedulingPolicy;


These defaults seem obsolete now

paulquiring requested a deployment to workflow-approval June 15, 2026 14:18 — with GitHub Actions Waiting

paulquiring requested a deployment to workflow-approval June 16, 2026 06:42 — with GitHub Actions Waiting

paulquiring commented Jun 16, 2026

View reviewed changes

Comment thread scripts/config_mapping/lifecycle_config.py

paulquiring marked this pull request as ready for review June 16, 2026 08:02

paulquiring requested a review from NicolasFussberger June 16, 2026 08:02