Initial mw::com-based implementation of ilmcontrol interface by NicolasFussberger · Pull Request #478 · eclipse-score/lifecycle

NicolasFussberger · 2026-08-17T09:18:03Z

Initial implementation of the ilm_control interface using mw::com as the underlying communication framework.
This PR only implements the library-side.
Follow up PR will adapt the launch_manager daemon code to interact with the library via mw::com.

Closes: #480

github-actions · 2026-08-17T09:19:18Z

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.6.0) and connecting to it...
INFO: Invocation ID: 2f8563d1-0844-46a0-8a5a-5f7567edb6fa
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: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

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

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

Analyzing: target //:license-check (146 packages loaded, 1059 targets configured)

Analyzing: target //:license-check (159 packages loaded, 4554 targets configured)

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

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

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

Analyzing: target //:license-check (176 packages loaded, 11463 targets configured)

Analyzing: target //:license-check (176 packages loaded, 11463 targets configured)

INFO: Analyzed target //:license-check (177 packages loaded, 11589 targets configured).
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: 24.923s, Critical Path: 0.45s
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>]

github-actions · 2026-08-17T09:31:39Z

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

NicolasFussberger · 2026-08-21T07:42:56Z

Following up on #495 — since this interface is explicitly marked as WIP ("API shape not yet finalised"), raising this now while it's still easy to adjust.

ActivationCallback/ActivationResult currently reports RunTargetActivationSource (kStateManagerRequest vs kRecoveryAction), but when a recovery-driven switch happens, there's no way to learn why — which Process/Process Group failed, or with what error. #495 was asking for exactly this kind of diagnostic (GetExecutionError()/ExecutionErrorEvent), and that path is being removed entirely by #489.

Would it be feasible to carry an optional diagnostic payload on ActivationResult when activation_source == kRecoveryAction? The type already exists in the tree — score/launch_manager/src/execution_error_event.h's ExecutionErrorEvent{executionError, processGroup} — so this may just be a matter of threading an existing type through rather than designing something new.

Happy to open this as its own tracked issue instead of a PR comment if that's preferred.

Hi @hskang-amelia,

yes this is a fair point. We briefly discussed this use case before and there was no great solution that came up immediately and no strong opinion that it needs to be available in the first version. That's why it is not part of this initial PR. We were not sure what kind of error reporting is the best approach as there may be multiple errors that lead to the final RunTarget activation.
For example:

Start Transition to RunTarget A
Failure to start component C1 & C2
Recovery Action starts transition to RunTarget B
failure to start component C3
Launch Manager transitions to final "fallback run target"
fallback run target successfully activated

In the current interface design, StateManager is informed that "fallback run target" has been successfully activated with kRecoveryAction activation source. Based on the feedback in SCore, these intermediate transitions were not required to be communicated so only the final RunTarget activation is communicated.
So in this example there is a chain of errors for C1, C2 and C3 that lead to the final RunTarget.
I am not clear whether it would be enough to just communicate the very first error that was observed (e.g. C1)

I think it would be a good idea to track this in a separate issue as you suggested.
You are also welcome to join the regular lifecycle meeting for further discussion of this issue.

NicolasFussberger · 2026-08-24T06:48:36Z

Following up on #495 — since this interface is explicitly marked as WIP ("API shape not yet finalised"), raising this now while it's still easy to adjust.
ActivationCallback/ActivationResult currently reports RunTargetActivationSource (kStateManagerRequest vs kRecoveryAction), but when a recovery-driven switch happens, there's no way to learn why — which Process/Process Group failed, or with what error. #495 was asking for exactly this kind of diagnostic (GetExecutionError()/ExecutionErrorEvent), and that path is being removed entirely by #489.
Would it be feasible to carry an optional diagnostic payload on ActivationResult when activation_source == kRecoveryAction? The type already exists in the tree — score/launch_manager/src/execution_error_event.h's ExecutionErrorEvent{executionError, processGroup} — so this may just be a matter of threading an existing type through rather than designing something new.
Happy to open this as its own tracked issue instead of a PR comment if that's preferred.

Hi @hskang-amelia,

yes this is a fair point. We briefly discussed this use case before and there was no great solution that came up immediately and no strong opinion that it needs to be available in the first version. That's why it is not part of this initial PR. We were not sure what kind of error reporting is the best approach as there may be multiple errors that lead to the final RunTarget activation. For example:
1. Start Transition to RunTarget A

2. Failure to start component C1 & C2

3. Recovery Action starts transition to RunTarget B

4. failure to start component C3

5. Launch Manager transitions to final "fallback run target"

6. fallback run target successfully activated
In the current interface design, StateManager is informed that "fallback run target" has been successfully activated with kRecoveryAction activation source. Based on the feedback in SCore, these intermediate transitions were not required to be communicated so only the final RunTarget activation is communicated. So in this example there is a chain of errors for C1, C2 and C3 that lead to the final RunTarget. I am not clear whether it would be enough to just communicate the very first error that was observed (e.g. C1)

I think it would be a good idea to track this in a separate issue as you suggested. You are also welcome to join the regular lifecycle meeting for further discussion of this issue.

I am collecting any open points regarding control API here #509 and I have created a subissue for the error information #511

…based_api

hskang-amelia · 2026-08-24T15:34:07Z

+      "instances": [
+        {
+          "instanceId": 1,
+          "asil-level": "QM",


Should this instance set permission-checks and allowedConsumer? With both absent, SkeletonMemoryManager falls back to WorldWritable for the control channel, so any local process can attach a proxy and call ActivateRunTarget. The old ControlClient path restricted this by only handing the channel FD to processes marked StateManager in the manifest.
I know this is a test config, but it’s the only mw::com configuration in the repo so it’s what integrators will copy.

hskang-amelia · 2026-08-26T08:30:10Z

    /// @param[in] activationSource   What caused the activation to occur.
    /// @param[in] activatedRunTarget The Run Target that was activated - may
    ///                               differ from the one originally requested.
    using ActivationCallback =


RunTargetActivationSource only has kStateManagerRequest/kRecoveryAction, but the very first Run Target activation — the one Launch Manager performs on its own at boot, before any State Manager has connected or requested anything — is neither of those. It's not a State Manager request (no State Manager exists yet to make one), and it's not a recovery action either.

Does register_run_target_activation_callback's callback fire for that initial activation at all? The doc comment above says "the subscriber sees every settling," which reads as yes. If so, what RunTargetActivationSource value does it carry?

This matters for a State Manager that starts up after boot and wants to confirm the initial transition already happened correctly (rather than assuming success) — it needs a way to distinguish "this is the boot activation" from the two documented sources. Worth adding a third value (e.g. kInitialActivation), or is there a reason to fold it into one of the existing two?

I agree we should add a separate value for this. Since the daemon side is being implemented separately in #489, this had not been clarified yet.

MaciejKaszynski · 2026-08-26T13:39:50Z

I found that the score repo also has documentation on public APIs for features, so I made a task to update this once everything is public.
#536

SimonKozik and others added 19 commits August 14, 2026 11:18

Saving current status

611a4c3

Removing unneeded call to GetNewSamples

22d6798

Saving fixed versions for polling and SetReceiveHandler

964357b

Fix MODULE.bazel dependency

bfe62c7

Fix test case

5a94417

Refactor control client test

6ba5340

Use StartFindService API

842e16a

Use mw::log macros

4a8decb

Extend integration test

59c9f3e

LmControlImpl rework and UT

9868b59

Drop component tests

ded0df1

Drop integration tests

636ba66

Remove connected flag

4cb0906

Service discovery

9cdc689

Do not stop service discovery

7414686

init refactoring

d5c0e35

event read refactoring

55d6cec

Refactor callback invocation

0539aa1

Remove LmControlServer

52ce0ba

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

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

NicolasFussberger deployed to workflow-approval August 17, 2026 09:18 — with GitHub Actions Active

Cleanup

faa5d86

NicolasFussberger force-pushed the feature/new_mw_com_based_api branch from 1c88cfc to faa5d86 Compare August 17, 2026 09:28

NicolasFussberger requested a deployment to workflow-approval August 17, 2026 09:28 — with GitHub Actions Waiting

Fix compiler warning and tsan failure

45bfd31

NicolasFussberger added 2 commits August 21, 2026 08:54

Fix StartFindService race condition

8084005

Drop force detault param

c54ebd2

NicolasFussberger deployed to workflow-approval August 21, 2026 07:44 — with GitHub Actions Active

danth reviewed Aug 21, 2026

View reviewed changes

Comment thread score/launch_manager/src/lm_control/src/details/lm_control_service.h

NicolasFussberger mentioned this pull request Aug 24, 2026

Clarify required error information in lmcontrol API #511

Open

NicolasFussberger mentioned this pull request Aug 24, 2026

Possible API extension: Waiting for successful connection #512

Open

SimonKozik reviewed Aug 24, 2026

View reviewed changes

Comment thread score/launch_manager/src/lm_control/src/details/lm_control_impl.hpp Outdated

NicolasFussberger added 4 commits August 25, 2026 11:47

Merge remote-tracking branch 'upstream/main' into feature/new_mw_com_…

f19cd1f

…based_api

Remove noexcept from init

88105d6

Make init noexcept

a3e7b69

Reword log.hpp docmentation

64514a1

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

NicolasFussberger requested a deployment to workflow-approval August 26, 2026 07:23 — with GitHub Actions Waiting

Remove obsolete reject reason

fcf90ad

NicolasFussberger force-pushed the feature/new_mw_com_based_api branch from da973b1 to fcf90ad Compare August 26, 2026 07:32

NicolasFussberger deployed to workflow-approval August 26, 2026 07:32 — with GitHub Actions Active

Merge branch 'main' into feature/new_mw_com_based_api

c841d71

NicolasFussberger deployed to workflow-approval August 26, 2026 07:34 — with GitHub Actions Active

hskang-amelia mentioned this pull request Aug 26, 2026

Proposal: precompute IdentifierHash constants at config-generation time instead of hashing at runtime #529

Closed

TimoSteuerwaldETAS self-requested a review August 26, 2026 08:18

TimoSteuerwaldETAS approved these changes Aug 26, 2026

View reviewed changes

hskang-amelia reviewed Aug 26, 2026

View reviewed changes

MaciejKaszynski reviewed Aug 26, 2026

View reviewed changes

Navigation Menu

Uh oh!

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

Initial mw::com-based implementation of ilmcontrol interface#478
NicolasFussberger wants to merge 44 commits into
eclipse-score:mainfrom
etas-contrib:feature/new_mw_com_based_api

NicolasFussberger commented Aug 17, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 17, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 17, 2026

Uh oh!

NicolasFussberger commented Aug 21, 2026

Uh oh!

Uh oh!

NicolasFussberger commented Aug 24, 2026 •

edited

Loading

Uh oh!

Uh oh!

hskang-amelia Aug 24, 2026

Uh oh!

hskang-amelia Aug 26, 2026

Uh oh!

danth Aug 26, 2026

Uh oh!

MaciejKaszynski Aug 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

NicolasFussberger commented Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

License Check Results

Uh oh!

github-actions Bot commented Aug 17, 2026

Uh oh!

NicolasFussberger commented Aug 21, 2026

Uh oh!

Uh oh!

NicolasFussberger commented Aug 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

hskang-amelia Aug 24, 2026

Choose a reason for hiding this comment

Uh oh!

hskang-amelia Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

danth Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

MaciejKaszynski Aug 26, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

NicolasFussberger commented Aug 17, 2026 •

edited

Loading

github-actions Bot commented Aug 17, 2026 •

edited

Loading

NicolasFussberger commented Aug 24, 2026 •

edited

Loading